date:20160412

[PATCH 3/3] Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 991de2e59090e55c65a7f59a049142e3c480f7bd.

Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090.  Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3.  In both cases booting with
"pci=routirq" is a workaround.

I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges.  Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.

Revert 991de2e59090 to fix these driver regressions.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз 
Reported-by: Sunjin Yang 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
---
 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |7 ++-
 arch/x86/pci/irq.c |   15 ++-
 drivers/acpi/pci_irq.c |9 -
 5 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..164e3f8 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,6 +93,8 @@ extern raw_spinlock_t pci_config_lock;
 extern int (*pcibios_enable_irq)(struct pci_dev *dev);
 extern void (*pcibios_disable_irq)(struct pci_dev *dev);
 
+extern bool mp_should_keep_irq(struct device *dev);
+
 struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index dc78a4a..8fd6f44 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,20 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
-int pcibios_alloc_irq(struct pci_dev *dev)
+int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
-   return pcibios_enable_irq(dev);
-}
+   int err;
 
-void pcibios_free_irq(struct pci_dev *dev)
-{
-   if (pcibios_disable_irq)
-   pcibios_disable_irq(dev);
+   if ((err = pci_enable_resources(dev, mask)) < 0)
+   return err;
+
+   if (!pci_dev_msi_enabled(dev))
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+void pcibios_disable_device (struct pci_dev *dev)
 {
-   return pci_enable_resources(dev, mask);
+   if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+   pcibios_disable_irq(dev);
 }
 
 int pci_ext_cfg_avail(void)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 8826ff5..8b93e63 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -256,13 +256,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (dev->irq_managed && dev->irq > 0) {
+   if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
+   dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
-   /*
-* Don't reset dev->irq here, otherwise
-* intel_mid_pci_irq_enable() will fail on next call.
-*/
}
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 72108f0..9bd1154 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1257,9 +1257,22 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
 }
 
+bool mp_should_keep_irq(struct device *dev)
+{
+   if (dev->power.is_prepared)
+   return true;
+#ifdef CONFIG_PM
+   if (dev->power.runtime_status == RPM_SUSPENDING)
+   return true;
+#endif
+
+   return false;
+}
+
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
+   dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 172b74d..8a10a7a 100644
---

[PATCH 2/3] Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 811a4e6fce09bc9239c664c6a1a53645a678c303.

Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |4 ++--
 arch/x86/pci/irq.c   |   10 ++
 drivers/acpi/pci_irq.c   |   10 ++
 include/linux/pci.h  |   17 -
 4 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 0d24e7c..8826ff5 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -215,7 +215,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
int polarity;
int ret;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
switch (intel_mid_identify_cpu()) {
@@ -256,7 +256,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (pci_has_managed_irq(dev)) {
+   if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 32e7034..72108f0 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,7 +1202,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1230,7 +1230,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
-   pci_set_managed_irq(dev, irq);
+   dev->irq_managed = 1;
+   dev->irq = irq;
dev_info(>dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
return 0;
@@ -1258,8 +1259,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
 
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
+   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
-   pci_reset_managed_irq(dev);
+   dev->irq = 0;
+   dev->irq_managed = 0;
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c933675..172b74d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -409,7 +409,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -454,7 +454,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
-   pci_set_managed_irq(dev, rc);
+   dev->irq = rc;
+   dev->irq_managed = 1;
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -477,7 +478,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin || !pci_has_managed_irq(dev))
+   if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -499,6 +500,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
-   pci_reset_managed_irq(dev);
+   dev->irq_managed = 0;
+   dev->irq = 0;
}
 }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6ae25aa..1cca5d8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -988,23 +988,6 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
 }
 
-static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
-{
-   pdev->irq = irq;
-   pdev->irq_managed = 1;
-}
-
-static inline void pci_reset_managed_irq(struct pci_dev *pdev)
-{
-   pdev->irq = 0;
-   pdev->irq_managed = 0;
-}
-

[PATCH 3/3] Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 991de2e59090e55c65a7f59a049142e3c480f7bd.

Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090.  Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3.  In both cases booting with
"pci=routirq" is a workaround.

I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges.  Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.

Revert 991de2e59090 to fix these driver regressions.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз 
Reported-by: Sunjin Yang 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
---
 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |7 ++-
 arch/x86/pci/irq.c |   15 ++-
 drivers/acpi/pci_irq.c |9 -
 5 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..164e3f8 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,6 +93,8 @@ extern raw_spinlock_t pci_config_lock;
 extern int (*pcibios_enable_irq)(struct pci_dev *dev);
 extern void (*pcibios_disable_irq)(struct pci_dev *dev);
 
+extern bool mp_should_keep_irq(struct device *dev);
+
 struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index dc78a4a..8fd6f44 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,20 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
-int pcibios_alloc_irq(struct pci_dev *dev)
+int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
-   return pcibios_enable_irq(dev);
-}
+   int err;
 
-void pcibios_free_irq(struct pci_dev *dev)
-{
-   if (pcibios_disable_irq)
-   pcibios_disable_irq(dev);
+   if ((err = pci_enable_resources(dev, mask)) < 0)
+   return err;
+
+   if (!pci_dev_msi_enabled(dev))
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+void pcibios_disable_device (struct pci_dev *dev)
 {
-   return pci_enable_resources(dev, mask);
+   if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+   pcibios_disable_irq(dev);
 }
 
 int pci_ext_cfg_avail(void)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 8826ff5..8b93e63 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -256,13 +256,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (dev->irq_managed && dev->irq > 0) {
+   if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
+   dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
-   /*
-* Don't reset dev->irq here, otherwise
-* intel_mid_pci_irq_enable() will fail on next call.
-*/
}
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 72108f0..9bd1154 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1257,9 +1257,22 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
 }
 
+bool mp_should_keep_irq(struct device *dev)
+{
+   if (dev->power.is_prepared)
+   return true;
+#ifdef CONFIG_PM
+   if (dev->power.runtime_status == RPM_SUSPENDING)
+   return true;
+#endif
+
+   return false;
+}
+
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
+   dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 172b74d..8a10a7a 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -481,6 +481,14 @@ void acpi_pci_irq_disable(struct pci_dev

[PATCH 2/3] Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 811a4e6fce09bc9239c664c6a1a53645a678c303.

Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |4 ++--
 arch/x86/pci/irq.c   |   10 ++
 drivers/acpi/pci_irq.c   |   10 ++
 include/linux/pci.h  |   17 -
 4 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 0d24e7c..8826ff5 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -215,7 +215,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
int polarity;
int ret;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
switch (intel_mid_identify_cpu()) {
@@ -256,7 +256,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (pci_has_managed_irq(dev)) {
+   if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 32e7034..72108f0 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,7 +1202,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1230,7 +1230,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
-   pci_set_managed_irq(dev, irq);
+   dev->irq_managed = 1;
+   dev->irq = irq;
dev_info(>dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
return 0;
@@ -1258,8 +1259,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
 
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
+   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
-   pci_reset_managed_irq(dev);
+   dev->irq = 0;
+   dev->irq_managed = 0;
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c933675..172b74d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -409,7 +409,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -454,7 +454,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
-   pci_set_managed_irq(dev, rc);
+   dev->irq = rc;
+   dev->irq_managed = 1;
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -477,7 +478,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin || !pci_has_managed_irq(dev))
+   if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -499,6 +500,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
-   pci_reset_managed_irq(dev);
+   dev->irq_managed = 0;
+   dev->irq = 0;
}
 }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 6ae25aa..1cca5d8 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -988,23 +988,6 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
 }
 
-static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
-{
-   pdev->irq = irq;
-   pdev->irq_managed = 1;
-}
-
-static inline void pci_reset_managed_irq(struct pci_dev *pdev)
-{
-   pdev->irq = 0;
-   pdev->irq_managed = 0;
-}
-
-static inline bool pci_has_managed_irq(struct pci_dev *pdev)
-{
-

[PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

2016-04-12 Thread Bjorn Helgaas

pcibios_free_irq()"

Please apply these reverts to the v4.4 stable kernel.

We reverted the following changes from v4.5 to fix a regression:

  8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled")
  811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed")
  991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")

but I forgot to mark those reverts for stable.  This series contains the
backports for v4.4.

For reference, the v4.5 reverts are:

  fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"")
  67b4eab91caf ("Revert "PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed"")
  6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()"")

---

Bjorn Helgaas (3):
  Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
  Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
  Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"


 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   26 ++
 arch/x86/pci/intel_mid_pci.c   |9 +++--
 arch/x86/pci/irq.c |   23 +++
 drivers/acpi/pci_irq.c |   17 +
 include/linux/pci.h|   17 -
 6 files changed, 47 insertions(+), 47 deletions(-)

[PATCH 1/3] Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 8affb487d4a4e223d961d7034cb41cd31982b618.

Revert 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is
enabled").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
CC: Joerg Roedel 
---
 arch/x86/pci/common.c |8 
 1 file changed, 8 deletions(-)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index eccd4d9..dc78a4a 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -675,14 +675,6 @@ int pcibios_add_device(struct pci_dev *dev)
 
 int pcibios_alloc_irq(struct pci_dev *dev)
 {
-   /*
-* If the PCI device was already claimed by core code and has
-* MSI enabled, probing of the pcibios IRQ will overwrite
-* dev->irq.  So bail out if MSI is already enabled.
-*/
-   if (pci_dev_msi_enabled(dev))
-   return -EBUSY;
-
return pcibios_enable_irq(dev);
 }

[PATCH 1/3] Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 8affb487d4a4e223d961d7034cb41cd31982b618.

Revert 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is
enabled").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.4
CC: Jiang Liu 
CC: Joerg Roedel 
---
 arch/x86/pci/common.c |8 
 1 file changed, 8 deletions(-)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index eccd4d9..dc78a4a 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -675,14 +675,6 @@ int pcibios_add_device(struct pci_dev *dev)
 
 int pcibios_alloc_irq(struct pci_dev *dev)
 {
-   /*
-* If the PCI device was already claimed by core code and has
-* MSI enabled, probing of the pcibios IRQ will overwrite
-* dev->irq.  So bail out if MSI is already enabled.
-*/
-   if (pci_dev_msi_enabled(dev))
-   return -EBUSY;
-
return pcibios_enable_irq(dev);
 }

[PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

2016-04-12 Thread Bjorn Helgaas

pcibios_free_irq()"

Please apply these reverts to the v4.4 stable kernel.

We reverted the following changes from v4.5 to fix a regression:

  8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is enabled")
  811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed")
  991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")

but I forgot to mark those reverts for stable.  This series contains the
backports for v4.4.

For reference, the v4.5 reverts are:

  fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"")
  67b4eab91caf ("Revert "PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed"")
  6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()"")

---

Bjorn Helgaas (3):
  Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
  Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
  Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"


 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   26 ++
 arch/x86/pci/intel_mid_pci.c   |9 +++--
 arch/x86/pci/irq.c |   23 +++
 drivers/acpi/pci_irq.c |   17 +
 include/linux/pci.h|   17 -
 6 files changed, 47 insertions(+), 47 deletions(-)

[PATCH 0/2] v4.3: Revert "PCI: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

Please apply these reverts to the v4.3 stable kernel.

We reverted the following changes from v4.6 to fix a regression:

  811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed")
  991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")

but I forgot to mark those reverts for stable.  This series contains the
backports for v4.3.

For reference, the v4.6 reverts are:

  fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"")
  67b4eab91caf ("Revert "PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed"")
  6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()"")

The revert of "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
is not included in this series because that commit didn't appear until
v4.4, so it doesn't need to be reverted from v4.3.

---

Bjorn Helgaas (2):
  Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
  Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"


 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |9 +++--
 arch/x86/pci/irq.c |   23 +++
 drivers/acpi/pci_irq.c |   17 +
 include/linux/pci.h|   17 -
 6 files changed, 48 insertions(+), 40 deletions(-)

Re: Nokia N900 retention mode in v4.6, camera buttons fun

2016-04-12 Thread Tomi Valkeinen


On 12/04/16 19:30, Tony Lindgren wrote:

> With LCD enabled, both LEDs are on contantly. I think we should
> be able to hit retention in that state, at least n950 is doing it
> with the Nokia kernel.

N900's display needs constant updating, where N950's display has
internal framebuffer, allowing OMAP to be off.

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH 0/2] v4.3: Revert "PCI: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

Please apply these reverts to the v4.3 stable kernel.

We reverted the following changes from v4.6 to fix a regression:

  811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed")
  991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")

but I forgot to mark those reverts for stable.  This series contains the
backports for v4.3.

For reference, the v4.6 reverts are:

  fe25d078874f ("Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"")
  67b4eab91caf ("Revert "PCI: Add helpers to manage pci_dev->irq and 
pci_dev->irq_managed"")
  6c777e8799a9 ("Revert "PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()"")

The revert of "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
is not included in this series because that commit didn't appear until
v4.4, so it doesn't need to be reverted from v4.3.

---

Bjorn Helgaas (2):
  Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
  Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"


 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |9 +++--
 arch/x86/pci/irq.c |   23 +++
 drivers/acpi/pci_irq.c |   17 +
 include/linux/pci.h|   17 -
 6 files changed, 48 insertions(+), 40 deletions(-)

Re: Nokia N900 retention mode in v4.6, camera buttons fun

2016-04-12 Thread Tomi Valkeinen


On 12/04/16 19:30, Tony Lindgren wrote:

> With LCD enabled, both LEDs are on contantly. I think we should
> be able to hit retention in that state, at least n950 is doing it
> with the Nokia kernel.

N900's display needs constant updating, where N950's display has
internal framebuffer, allowing OMAP to be off.

 Tomi



signature.asc
Description: OpenPGP digital signature

[PATCH 1/2] Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 811a4e6fce09bc9239c664c6a1a53645a678c303.

Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.3
CC: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |4 ++--
 arch/x86/pci/irq.c   |   10 ++
 drivers/acpi/pci_irq.c   |   10 ++
 include/linux/pci.h  |   17 -
 4 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 0d24e7c..8826ff5 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -215,7 +215,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
int polarity;
int ret;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
switch (intel_mid_identify_cpu()) {
@@ -256,7 +256,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (pci_has_managed_irq(dev)) {
+   if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 32e7034..72108f0 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,7 +1202,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1230,7 +1230,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
-   pci_set_managed_irq(dev, irq);
+   dev->irq_managed = 1;
+   dev->irq = irq;
dev_info(>dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
return 0;
@@ -1258,8 +1259,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
 
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
+   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
-   pci_reset_managed_irq(dev);
+   dev->irq = 0;
+   dev->irq_managed = 0;
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c933675..172b74d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -409,7 +409,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -454,7 +454,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
-   pci_set_managed_irq(dev, rc);
+   dev->irq = rc;
+   dev->irq_managed = 1;
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -477,7 +478,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin || !pci_has_managed_irq(dev))
+   if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -499,6 +500,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
-   pci_reset_managed_irq(dev);
+   dev->irq_managed = 0;
+   dev->irq = 0;
}
 }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e90eb22..577c5fd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -978,23 +978,6 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
 }
 
-static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
-{
-   pdev->irq = irq;
-   pdev->irq_managed = 1;
-}
-
-static inline void pci_reset_managed_irq(struct pci_dev *pdev)
-{
-   pdev->irq = 0;
-   pdev->irq_managed = 0;
-}
-

[PATCH 2/2] Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 991de2e59090e55c65a7f59a049142e3c480f7bd.

991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090.  Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3.  In both cases booting with
"pci=routirq" is a workaround.

I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges.  Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.

Revert 991de2e59090 to fix these driver regressions.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз 
Reported-by: Sunjin Yang 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.3
CC: Jiang Liu 
---
 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |7 ++-
 arch/x86/pci/irq.c |   15 ++-
 drivers/acpi/pci_irq.c |9 -
 5 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..164e3f8 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,6 +93,8 @@ extern raw_spinlock_t pci_config_lock;
 extern int (*pcibios_enable_irq)(struct pci_dev *dev);
 extern void (*pcibios_disable_irq)(struct pci_dev *dev);
 
+extern bool mp_should_keep_irq(struct device *dev);
+
 struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index dc78a4a..8fd6f44 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,20 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
-int pcibios_alloc_irq(struct pci_dev *dev)
+int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
-   return pcibios_enable_irq(dev);
-}
+   int err;
 
-void pcibios_free_irq(struct pci_dev *dev)
-{
-   if (pcibios_disable_irq)
-   pcibios_disable_irq(dev);
+   if ((err = pci_enable_resources(dev, mask)) < 0)
+   return err;
+
+   if (!pci_dev_msi_enabled(dev))
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+void pcibios_disable_device (struct pci_dev *dev)
 {
-   return pci_enable_resources(dev, mask);
+   if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+   pcibios_disable_irq(dev);
 }
 
 int pci_ext_cfg_avail(void)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 8826ff5..8b93e63 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -256,13 +256,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (dev->irq_managed && dev->irq > 0) {
+   if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
+   dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
-   /*
-* Don't reset dev->irq here, otherwise
-* intel_mid_pci_irq_enable() will fail on next call.
-*/
}
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 72108f0..9bd1154 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1257,9 +1257,22 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
 }
 
+bool mp_should_keep_irq(struct device *dev)
+{
+   if (dev->power.is_prepared)
+   return true;
+#ifdef CONFIG_PM
+   if (dev->power.runtime_status == RPM_SUSPENDING)
+   return true;
+#endif
+
+   return false;
+}
+
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
+   dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 172b74d..8a10a7a 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -481,6 +481,14 @@

[PATCH 1/2] Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 811a4e6fce09bc9239c664c6a1a53645a678c303.

Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").

This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.3
CC: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |4 ++--
 arch/x86/pci/irq.c   |   10 ++
 drivers/acpi/pci_irq.c   |   10 ++
 include/linux/pci.h  |   17 -
 4 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 0d24e7c..8826ff5 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -215,7 +215,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
int polarity;
int ret;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
switch (intel_mid_identify_cpu()) {
@@ -256,7 +256,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (pci_has_managed_irq(dev)) {
+   if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 32e7034..72108f0 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,7 +1202,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1230,7 +1230,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
-   pci_set_managed_irq(dev, irq);
+   dev->irq_managed = 1;
+   dev->irq = irq;
dev_info(>dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
return 0;
@@ -1258,8 +1259,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
 
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
+   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
-   pci_reset_managed_irq(dev);
+   dev->irq = 0;
+   dev->irq_managed = 0;
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c933675..172b74d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -409,7 +409,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
-   if (pci_has_managed_irq(dev))
+   if (dev->irq_managed && dev->irq > 0)
return 0;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -454,7 +454,8 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
-   pci_set_managed_irq(dev, rc);
+   dev->irq = rc;
+   dev->irq_managed = 1;
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -477,7 +478,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin || !pci_has_managed_irq(dev))
+   if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -499,6 +500,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
-   pci_reset_managed_irq(dev);
+   dev->irq_managed = 0;
+   dev->irq = 0;
}
 }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e90eb22..577c5fd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -978,23 +978,6 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
 }
 
-static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
-{
-   pdev->irq = irq;
-   pdev->irq_managed = 1;
-}
-
-static inline void pci_reset_managed_irq(struct pci_dev *pdev)
-{
-   pdev->irq = 0;
-   pdev->irq_managed = 0;
-}
-
-static inline bool pci_has_managed_irq(struct pci_dev *pdev)
-{
-

[PATCH 2/2] Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"

2016-04-12 Thread Bjorn Helgaas

This reverts commit 991de2e59090e55c65a7f59a049142e3c480f7bd.

991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.

Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090.  Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3.  In both cases booting with
"pci=routirq" is a workaround.

I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges.  Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().

After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.

Revert 991de2e59090 to fix these driver regressions.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and 
pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз 
Reported-by: Sunjin Yang 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: sta...@vger.kernel.org  # v4.3
CC: Jiang Liu 
---
 arch/x86/include/asm/pci_x86.h |2 ++
 arch/x86/pci/common.c  |   20 +++-
 arch/x86/pci/intel_mid_pci.c   |7 ++-
 arch/x86/pci/irq.c |   15 ++-
 drivers/acpi/pci_irq.c |9 -
 5 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index fa1195d..164e3f8 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,6 +93,8 @@ extern raw_spinlock_t pci_config_lock;
 extern int (*pcibios_enable_irq)(struct pci_dev *dev);
 extern void (*pcibios_disable_irq)(struct pci_dev *dev);
 
+extern bool mp_should_keep_irq(struct device *dev);
+
 struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index dc78a4a..8fd6f44 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,20 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
-int pcibios_alloc_irq(struct pci_dev *dev)
+int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
-   return pcibios_enable_irq(dev);
-}
+   int err;
 
-void pcibios_free_irq(struct pci_dev *dev)
-{
-   if (pcibios_disable_irq)
-   pcibios_disable_irq(dev);
+   if ((err = pci_enable_resources(dev, mask)) < 0)
+   return err;
+
+   if (!pci_dev_msi_enabled(dev))
+   return pcibios_enable_irq(dev);
+   return 0;
 }
 
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+void pcibios_disable_device (struct pci_dev *dev)
 {
-   return pci_enable_resources(dev, mask);
+   if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+   pcibios_disable_irq(dev);
 }
 
 int pci_ext_cfg_avail(void)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 8826ff5..8b93e63 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -256,13 +256,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (dev->irq_managed && dev->irq > 0) {
+   if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
+   dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
-   /*
-* Don't reset dev->irq here, otherwise
-* intel_mid_pci_irq_enable() will fail on next call.
-*/
}
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 72108f0..9bd1154 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1257,9 +1257,22 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
 }
 
+bool mp_should_keep_irq(struct device *dev)
+{
+   if (dev->power.is_prepared)
+   return true;
+#ifdef CONFIG_PM
+   if (dev->power.runtime_status == RPM_SUSPENDING)
+   return true;
+#endif
+
+   return false;
+}
+
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
+   dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 172b74d..8a10a7a 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -481,6 +481,14 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (!pin || !dev->irq_managed || dev->irq <= 0)

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

2016-04-12 Thread Jingoo Han

On Tuesday, April 12, 2016 6:44 PM, Gabriele Paoloni wrote:
> 
> Hi Bjorn
> 
> [...]
> 
> > > >
> > > > What's the hisi plan for resuming after suspend-to-RAM?  How does
> > the
> > > > RC get reprogrammed after it loses all its state?
> > >
> > > PM is not part of the driver yet. This is planned for near
> > > future release so haven't made such considerations yet
> > > >
> > > > What would break if hisi did call dw_pcie_setup_rc()?  I know you
> > said
> > > > it would overwrite what the bootloader already did, which is true.
> > >
> > > I am try to figure this out now with our HW team.
> > >
> > > >
> > > > But hisi does call dw_pcie_host_init(), so it reads pp->mem (which
> > > > determines pp->mem_base) and pp->lanes from the DT.  Other drivers
> > > > then call dw_pcie_setup_rc() which programs the RC based on
> > > > pp->mem_base and pp->lanes.  So hisi assumes UEFI programmed the RC
> > to
> > > > match the DT, while the other drivers read the DT and program the
> > RC
> > > > to match.  The latter seems more robust because it enforces the
> > > > consistency rather than relying on it.
> > >
> > > Yes I agree with you, however we have preferred to move RC config to
> > > BIOS to have a single driver to support multiple versions of the
> > > same SoC.
> >
> > I think there are two reasonable approaches:
> >
> >   1) A single generic driver that doesn't have any knowledge about the
> >   chipset registers; it uses run-time firmware interfaces to manage
> >   the bridge.  The ACPI pci_root.c driver is the best example so far
> >   and works very well.  It supports basically all x86 and ia64
> >   chipsets and requires no kernel work for new ones.
> >
> >   2) Native drivers specific to each chipset.  These may get
> >   configuration information from DT, but they do their own
> >   register-level programming of the device without run-time help from
> >   firmware.
> >
> > I think hisi is a native driver because it uses hip05/hip06 registers
> > to check link state and perform config operations.  And apparently you
> > rely on the ATU, BAR, class, and link width programming currently done
> > in dw_pcie_host_init().  But you want to rely on pre-boot firmware to
> > set up the link.  That doesn't make sense to me -- if the driver wants
> > to twiddle the registers, it should know how to do it all.  I don't
> > see how you can reasonably manage this half-way approach.
> >
> > > The patch I proposed above does the same job as the original patch
> > > proposed by Jisheng and also allows hisi driver to call the moved
> > > code.
> > >
> > > Do you see anything wrong with it?
> >
> > Only that it makes the structure more complicated and we haven't
> > identified a corresponding benefit yet.
> 
> Finally I have checked that assigning .host_init function pointer
> in our driver to call dw_pcie_setup_rc() will not affect the values
> already set by BIOS.
> 
> Also I agree with you that a hybrid approach is not ideal.

I also agree with Bjorn's opinion.
As far as I know, two approaches are reasonable.

In the case of using UEFI, how about using 'pci-host-generic.c'?
You may consult with Linaro guys for this issue.
Good luck.

Best regards,
Jingoo Han

> 
> So I will update the driver to call dw_pcie_setup_rc() from
> .host_init and ask the BIOS team to update the firmware for next
> releases (the driver will be backward compatible anyway).
> 
> Also during my investigation I have noticed that in dw_pcie_setup_rc()
> http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L762
> 
> we use pp->mem_base rather than pp->mem_bus_addr to setup
> memory base and memory limit in the Type1 header...I think this
> is wrong right?
> Also I do not see why this code is needed at all since we overwrite
> this register when we call pci_bus_assign_resources(bus) that
> will end up in calling pci_setup_bridge() and then
> pci_setup_bridge_mmio()...?
> 
> Many Thanks
> 
> Gab
> 
> >
> > Bjorn
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc()

2016-04-12 Thread Jingoo Han

On Tuesday, April 12, 2016 6:44 PM, Gabriele Paoloni wrote:
> 
> Hi Bjorn
> 
> [...]
> 
> > > >
> > > > What's the hisi plan for resuming after suspend-to-RAM?  How does
> > the
> > > > RC get reprogrammed after it loses all its state?
> > >
> > > PM is not part of the driver yet. This is planned for near
> > > future release so haven't made such considerations yet
> > > >
> > > > What would break if hisi did call dw_pcie_setup_rc()?  I know you
> > said
> > > > it would overwrite what the bootloader already did, which is true.
> > >
> > > I am try to figure this out now with our HW team.
> > >
> > > >
> > > > But hisi does call dw_pcie_host_init(), so it reads pp->mem (which
> > > > determines pp->mem_base) and pp->lanes from the DT.  Other drivers
> > > > then call dw_pcie_setup_rc() which programs the RC based on
> > > > pp->mem_base and pp->lanes.  So hisi assumes UEFI programmed the RC
> > to
> > > > match the DT, while the other drivers read the DT and program the
> > RC
> > > > to match.  The latter seems more robust because it enforces the
> > > > consistency rather than relying on it.
> > >
> > > Yes I agree with you, however we have preferred to move RC config to
> > > BIOS to have a single driver to support multiple versions of the
> > > same SoC.
> >
> > I think there are two reasonable approaches:
> >
> >   1) A single generic driver that doesn't have any knowledge about the
> >   chipset registers; it uses run-time firmware interfaces to manage
> >   the bridge.  The ACPI pci_root.c driver is the best example so far
> >   and works very well.  It supports basically all x86 and ia64
> >   chipsets and requires no kernel work for new ones.
> >
> >   2) Native drivers specific to each chipset.  These may get
> >   configuration information from DT, but they do their own
> >   register-level programming of the device without run-time help from
> >   firmware.
> >
> > I think hisi is a native driver because it uses hip05/hip06 registers
> > to check link state and perform config operations.  And apparently you
> > rely on the ATU, BAR, class, and link width programming currently done
> > in dw_pcie_host_init().  But you want to rely on pre-boot firmware to
> > set up the link.  That doesn't make sense to me -- if the driver wants
> > to twiddle the registers, it should know how to do it all.  I don't
> > see how you can reasonably manage this half-way approach.
> >
> > > The patch I proposed above does the same job as the original patch
> > > proposed by Jisheng and also allows hisi driver to call the moved
> > > code.
> > >
> > > Do you see anything wrong with it?
> >
> > Only that it makes the structure more complicated and we haven't
> > identified a corresponding benefit yet.
> 
> Finally I have checked that assigning .host_init function pointer
> in our driver to call dw_pcie_setup_rc() will not affect the values
> already set by BIOS.
> 
> Also I agree with you that a hybrid approach is not ideal.

I also agree with Bjorn's opinion.
As far as I know, two approaches are reasonable.

In the case of using UEFI, how about using 'pci-host-generic.c'?
You may consult with Linaro guys for this issue.
Good luck.

Best regards,
Jingoo Han

> 
> So I will update the driver to call dw_pcie_setup_rc() from
> .host_init and ask the BIOS team to update the firmware for next
> releases (the driver will be backward compatible anyway).
> 
> Also during my investigation I have noticed that in dw_pcie_setup_rc()
> http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L762
> 
> we use pp->mem_base rather than pp->mem_bus_addr to setup
> memory base and memory limit in the Type1 header...I think this
> is wrong right?
> Also I do not see why this code is needed at all since we overwrite
> this register when we call pci_bus_assign_resources(bus) that
> will end up in calling pci_setup_bridge() and then
> pci_setup_bridge_mmio()...?
> 
> Many Thanks
> 
> Gab
> 
> >
> > Bjorn
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] arm64: dts: ls2080a: fsl-mc dt node updates

2016-04-12 Thread Shawn Guo

On Fri, Apr 01, 2016 at 03:54:40PM -0500, Stuart Yoder wrote:
> From: Stuart Yoder 
> 
> updates to the fsl-mc node for full functionality:
>-msi-parent is needed for interrupt support
>-ranges is needed to enable the bus driver to translate bus addresses
>-dpmac nodes provide a basis for relating dpmac objects to PHYs
> 
> Signed-off-by: Stuart Yoder 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   87 
> 
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 9d746c6..449c635 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -265,6 +265,93 @@
>   compatible = "fsl,qoriq-mc";
>   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
> base */
> <0x 0x0834 0 0x4>; /* MC control 
> reg */
> + msi-parent = <>;
> + #address-cells = <3>;
> + #size-cells = <1>;
> +
> + /*
> +  * Region type 0x0 - MC portals
> +  * Region type 0x1 - QBMAN portals
> +  */
> + ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
> +   0x1 0x0 0x0 0x8 0x1800 0x800>;
> +
> + /*
> +  * Define the maximum number of MACs present on the SoC.
> +  * They won't necessarily be all probed, since the
> +  * Data Path Layout file and the MC firmware can put
> +  * fewer actual DPMAC objects on the MC bus.
> +  */
> + dpmacs {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpmac1: dpmac@1 {
> + compatible = "fsl,qoriq-mc-dpmac";

I did not see how this compatible is used by kernel driver.

> + reg = <1>;
> + };

Please have a newline between nodes.

Shawn

> + dpmac2: dpmac@2 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <2>;
> + };
> + dpmac3: dpmac@3 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <3>;
> + };
> + dpmac4: dpmac@4 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <4>;
> + };
> + dpmac5: dpmac@5 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <5>;
> + };
> + dpmac6: dpmac@6 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <6>;
> + };
> + dpmac7: dpmac@7 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <7>;
> + };
> + dpmac8: dpmac@8 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <8>;
> + };
> + dpmac9: dpmac@9 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <9>;
> + };
> + dpmac10: dpmac@10 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xa>;
> + };
> + dpmac11: dpmac@11 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xb>;
> + };
> + dpmac12: dpmac@12 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xc>;
> + };
> + dpmac13: dpmac@13 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xd>;
> + };
> + dpmac14: dpmac@14 {
> + compatible = "fsl,qoriq-mc-dpmac";
>

Re: [PATCH 2/2] arm64: dts: ls2080a: fsl-mc dt node updates

2016-04-12 Thread Shawn Guo

On Fri, Apr 01, 2016 at 03:54:40PM -0500, Stuart Yoder wrote:
> From: Stuart Yoder 
> 
> updates to the fsl-mc node for full functionality:
>-msi-parent is needed for interrupt support
>-ranges is needed to enable the bus driver to translate bus addresses
>-dpmac nodes provide a basis for relating dpmac objects to PHYs
> 
> Signed-off-by: Stuart Yoder 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |   87 
> 
>  1 file changed, 87 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 9d746c6..449c635 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -265,6 +265,93 @@
>   compatible = "fsl,qoriq-mc";
>   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
> base */
> <0x 0x0834 0 0x4>; /* MC control 
> reg */
> + msi-parent = <>;
> + #address-cells = <3>;
> + #size-cells = <1>;
> +
> + /*
> +  * Region type 0x0 - MC portals
> +  * Region type 0x1 - QBMAN portals
> +  */
> + ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
> +   0x1 0x0 0x0 0x8 0x1800 0x800>;
> +
> + /*
> +  * Define the maximum number of MACs present on the SoC.
> +  * They won't necessarily be all probed, since the
> +  * Data Path Layout file and the MC firmware can put
> +  * fewer actual DPMAC objects on the MC bus.
> +  */
> + dpmacs {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpmac1: dpmac@1 {
> + compatible = "fsl,qoriq-mc-dpmac";

I did not see how this compatible is used by kernel driver.

> + reg = <1>;
> + };

Please have a newline between nodes.

Shawn

> + dpmac2: dpmac@2 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <2>;
> + };
> + dpmac3: dpmac@3 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <3>;
> + };
> + dpmac4: dpmac@4 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <4>;
> + };
> + dpmac5: dpmac@5 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <5>;
> + };
> + dpmac6: dpmac@6 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <6>;
> + };
> + dpmac7: dpmac@7 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <7>;
> + };
> + dpmac8: dpmac@8 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <8>;
> + };
> + dpmac9: dpmac@9 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <9>;
> + };
> + dpmac10: dpmac@10 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xa>;
> + };
> + dpmac11: dpmac@11 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xb>;
> + };
> + dpmac12: dpmac@12 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xc>;
> + };
> + dpmac13: dpmac@13 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xd>;
> + };
> + dpmac14: dpmac@14 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg =

[PATCH] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-04-12 Thread Vinay Simha BN

Add support for the JDI lt070me05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Other fixes folded in were provided
by Archit Taneja 

Signed-off-by: Vinay Simha BN 
[sumit.semwal: Ported to the drm/panel framework]
Signed-off-by: Sumit Semwal 
[jstultz: Cherry-picked to mainline, folded down other fixes
 from Vinay and Archit]
Signed-off-by: John Stultz 
---
 .../bindings/display/panel/jdi,lt070me05000.txt|  27 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 685 +
 5 files changed, 725 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
new file mode 100644
index 000..35c5ac7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
@@ -0,0 +1,27 @@
+JDI model LT070ME05000 1920x1200 7" DSI Panel
+
+Basic data sheet is at:
+   http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+
+This panel has video mode implemented currently in the driver.
+
+Required properties:
+- compatible: should be "jdi,lt070me05000"
+
+Optional properties:
+- power-supply: phandle of the regulator that provides the supply voltage
+- reset-gpio: phandle of gpio for reset line
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   dsi@5430 {
+   panel: panel@0 {
+   compatible = "jdi,lt070me05000";
+   reg = <0>;
+
+   power-supply = <...>;
+   reset-gpio = <...>;
+   backlight = <...>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a580f3e..ec42bb4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -130,6 +130,7 @@ invensense  InvenSense Inc.
 isee   ISEE 2007 S.L.
 isil   Intersil
 issi   Integrated Silicon Solutions Inc.
+jdiJapan Display Inc.
 jedec  JEDEC Solid State Technology Association
 karo   Ka-Ro electronics GmbH
 keymileKeymile GmbH
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..f41690e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -61,6 +61,17 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.
 
+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI WUXGA DSI video/
+ command mode panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit RGB per pixel.
+
 config DRM_PANEL_SHARP_LS043T1LE01
tristate "Sharp LS043T1LE01 qHD video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..e6c6fc8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..051aa1b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,685 @@
+/*
+ * Copyright (C) 2015 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2015 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ *

Re: [PATCH v2 3/3] mfd: mt6397: check the EPROBE_DEFER from platform_get_irq.

2016-04-12 Thread Henry Chen

On Mon, 2016-04-11 at 09:50 +0100, Lee Jones wrote:
> On Fri, 08 Apr 2016, Henry Chen wrote:
> 
> > If get the -EPROBE_DEFER from platform_get_irq, it should return back 
> > directly.
> > 
> > Signed-off-by: Henry Chen 
> > ---
> >  drivers/mfd/mt6397-core.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> > index 15050cb..b9b1e28 100644
> > --- a/drivers/mfd/mt6397-core.c
> > +++ b/drivers/mfd/mt6397-core.c
> > @@ -271,6 +271,8 @@ static int mt6397_probe(struct platform_device *pdev)
> > }
> >  
> > pmic->irq = platform_get_irq(pdev, 0);
> > +   if (pmic->irq == -EPROBE_DEFER)
> > +   return -EPROBE_DEFER;
> 
> if (ret < 0)
>return ret;
> 
> ... is more common, as it covers more bases, etc.

Okay, the interrupt should be a required properties, if get failed just
return back.

I will also change the binding doc.

Thanks.

> 
> > switch (id & 0xff) {
> > case MT6323_CID_CODE:
>

Re: [PATCH v2 3/3] mfd: mt6397: check the EPROBE_DEFER from platform_get_irq.

2016-04-12 Thread Henry Chen

On Mon, 2016-04-11 at 09:50 +0100, Lee Jones wrote:
> On Fri, 08 Apr 2016, Henry Chen wrote:
> 
> > If get the -EPROBE_DEFER from platform_get_irq, it should return back 
> > directly.
> > 
> > Signed-off-by: Henry Chen 
> > ---
> >  drivers/mfd/mt6397-core.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> > index 15050cb..b9b1e28 100644
> > --- a/drivers/mfd/mt6397-core.c
> > +++ b/drivers/mfd/mt6397-core.c
> > @@ -271,6 +271,8 @@ static int mt6397_probe(struct platform_device *pdev)
> > }
> >  
> > pmic->irq = platform_get_irq(pdev, 0);
> > +   if (pmic->irq == -EPROBE_DEFER)
> > +   return -EPROBE_DEFER;
> 
> if (ret < 0)
>return ret;
> 
> ... is more common, as it covers more bases, etc.

Okay, the interrupt should be a required properties, if get failed just
return back.

I will also change the binding doc.

Thanks.

> 
> > switch (id & 0xff) {
> > case MT6323_CID_CODE:
>

[PATCH] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-04-12 Thread Vinay Simha BN

Add support for the JDI lt070me05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Other fixes folded in were provided
by Archit Taneja 

Signed-off-by: Vinay Simha BN 
[sumit.semwal: Ported to the drm/panel framework]
Signed-off-by: Sumit Semwal 
[jstultz: Cherry-picked to mainline, folded down other fixes
 from Vinay and Archit]
Signed-off-by: John Stultz 
---
 .../bindings/display/panel/jdi,lt070me05000.txt|  27 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 685 +
 5 files changed, 725 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
new file mode 100644
index 000..35c5ac7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
@@ -0,0 +1,27 @@
+JDI model LT070ME05000 1920x1200 7" DSI Panel
+
+Basic data sheet is at:
+   http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+
+This panel has video mode implemented currently in the driver.
+
+Required properties:
+- compatible: should be "jdi,lt070me05000"
+
+Optional properties:
+- power-supply: phandle of the regulator that provides the supply voltage
+- reset-gpio: phandle of gpio for reset line
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   dsi@5430 {
+   panel: panel@0 {
+   compatible = "jdi,lt070me05000";
+   reg = <0>;
+
+   power-supply = <...>;
+   reset-gpio = <...>;
+   backlight = <...>;
+   };
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index a580f3e..ec42bb4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -130,6 +130,7 @@ invensense  InvenSense Inc.
 isee   ISEE 2007 S.L.
 isil   Intersil
 issi   Integrated Silicon Solutions Inc.
+jdiJapan Display Inc.
 jedec  JEDEC Solid State Technology Association
 karo   Ka-Ro electronics GmbH
 keymileKeymile GmbH
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..f41690e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -61,6 +61,17 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.
 
+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI WUXGA DSI video/
+ command mode panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit RGB per pixel.
+
 config DRM_PANEL_SHARP_LS043T1LE01
tristate "Sharp LS043T1LE01 qHD video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..e6c6fc8 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..051aa1b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,685 @@
+/*
+ * Copyright (C) 2015 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2015 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

2016-04-12 Thread Michael Ellerman

On Mon, 2016-04-11 at 03:32 -0300, Edjunior Barbosa Machado wrote:
> Hi Michael, Anshuman,
> 
> I've managed to implement the GDB support for the new regsets and test
> on Power8 (BE and LE).

Great work thanks!

> The following is an example of GDB 'info
> registers all' partial output showing the new registers when inside a
> suspended transaction on Power8 LE using this patchset. Please let me
> know if you need any additional information or tests from GDB side.

What's the plan for merging the gdb changes?

> (gdb) info registers all
> ...
> dscr   0x0  0
> ppr0xc  3377699720527872
> tar0x0  0
> ebbrr  
> ebbhr  
> bescr  
> siar   
> sdar   
> sier   
> mmcr2  
> mmcr0  
> tfhar  0x10002b30   268446512
> texasr 0x110980176561196215435265
> tfiar  0x10002ad9   268446425
> cr00x10002b2c   268446508

Using 'c' as the prefix is a bit confusing here, as 'cr0' is usually used to
refer to the CR0 field of CR.

Speaking of which, I don't see CR here? Or is it somewhere above in the ... ?

Maybe the prefix could be 'c_' ?

Or do other arches already use 'c' as the prefix?

Otherwise looks good.

cheers

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

2016-04-12 Thread Michael Ellerman

On Mon, 2016-04-11 at 03:32 -0300, Edjunior Barbosa Machado wrote:
> Hi Michael, Anshuman,
> 
> I've managed to implement the GDB support for the new regsets and test
> on Power8 (BE and LE).

Great work thanks!

> The following is an example of GDB 'info
> registers all' partial output showing the new registers when inside a
> suspended transaction on Power8 LE using this patchset. Please let me
> know if you need any additional information or tests from GDB side.

What's the plan for merging the gdb changes?

> (gdb) info registers all
> ...
> dscr   0x0  0
> ppr0xc  3377699720527872
> tar0x0  0
> ebbrr  
> ebbhr  
> bescr  
> siar   
> sdar   
> sier   
> mmcr2  
> mmcr0  
> tfhar  0x10002b30   268446512
> texasr 0x110980176561196215435265
> tfiar  0x10002ad9   268446425
> cr00x10002b2c   268446508

Using 'c' as the prefix is a bit confusing here, as 'cr0' is usually used to
refer to the CR0 field of CR.

Speaking of which, I don't see CR here? Or is it somewhere above in the ... ?

Maybe the prefix could be 'c_' ?

Or do other arches already use 'c' as the prefix?

Otherwise looks good.

cheers

Re: [lkp] [huge tmpfs] d7c7d56ca6: vm-scalability.throughput -5.5% regression

2016-04-12 Thread Hugh Dickins

On Wed, 13 Apr 2016, kernel test robot wrote:

> FYI, we noticed that vm-scalability.throughput -5.5% regression on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit d7c7d56ca61aec18e5e0cb3a64e50073c42195f7 ("huge tmpfs: avoid premature 
> exposure of new pagetable")

Very useful info, thank you.  I presume it confirms exactly what Kirill
warned me of, that doing the map_pages after instead of before the fault,
comes with a performance disadvantage.  I shall look into it, but not
immediately (and we know other reasons why that patch has to be revisited).

Hugh

> 
> 
> =
> compiler/cpufreq_governor/kconfig/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/300s/lkp-hsw01/lru-file-mmap-read-rand/vm-scalability
> 
> commit: 
>   517348161d2725b8b596feb10c813bf596dc6a47
>   d7c7d56ca61aec18e5e0cb3a64e50073c42195f7
> 
> 517348161d2725b8 d7c7d56ca61aec18e5e0cb3a64 
>  -- 
>fail:runs  %reproductionfail:runs
>| | |
>1801726 ±  0%  -5.5%1702808 ±  0%  vm-scalability.throughput
> 317.89 ±  0%  +2.9% 327.15 ±  0%  vm-scalability.time.elapsed_time
> 317.89 ±  0%  +2.9% 327.15 ±  0%  
> vm-scalability.time.elapsed_time.max
> 872240 ±  4%  +8.5% 946467 ±  1%  
> vm-scalability.time.involuntary_context_switches
>   6.73e+08 ±  0% -92.5%   50568722 ±  0%  
> vm-scalability.time.major_page_faults
>2109093 ±  9% -25.8%1564815 ±  7%  
> vm-scalability.time.maximum_resident_set_size
>  37881 ±  0%+586.9% 260194 ±  0%  
> vm-scalability.time.minor_page_faults
>   5087 ±  0%  +3.7%   5277 ±  0%  
> vm-scalability.time.percent_of_cpu_this_job_got
>  16047 ±  0%  +7.5%  17252 ±  0%  vm-scalability.time.system_time
> 127.19 ±  0% -88.3%  14.93 ±  1%  vm-scalability.time.user_time
>  72572 ±  7% +56.0% 113203 ±  3%  cpuidle.C1-HSW.usage
>  9.879e+08 ±  4% -32.5%   6.67e+08 ±  8%  cpuidle.C6-HSW.time
> 605545 ±  3% -12.9% 527295 ±  1%  softirqs.RCU
> 164170 ±  7% +20.5% 197881 ±  6%  softirqs.SCHED
>2584429 ±  3% -25.5%1925241 ±  2%  vmstat.memory.free
> 252507 ±  0% +36.2% 343994 ±  0%  vmstat.system.in
>  2.852e+08 ±  5%+163.9%  7.527e+08 ±  1%  numa-numastat.node0.local_node
>  2.852e+08 ±  5%+163.9%  7.527e+08 ±  1%  numa-numastat.node0.numa_hit
>  2.876e+08 ±  6%+162.8%  7.559e+08 ±  0%  numa-numastat.node1.local_node
>  2.876e+08 ±  6%+162.8%  7.559e+08 ±  0%  numa-numastat.node1.numa_hit
>   6.73e+08 ±  0% -92.5%   50568722 ±  0%  time.major_page_faults
>2109093 ±  9% -25.8%1564815 ±  7%  time.maximum_resident_set_size
>  37881 ±  0%+586.9% 260194 ±  0%  time.minor_page_faults
> 127.19 ±  0% -88.3%  14.93 ±  1%  time.user_time
>  94.37 ±  0%  +2.0%  96.27 ±  0%  turbostat.%Busy
>   2919 ±  0%  +2.0%   2977 ±  0%  turbostat.Avg_MHz
>   5.12 ±  4% -38.7%   3.14 ±  5%  turbostat.CPU%c6
>   2.00 ± 13% -44.8%   1.10 ± 22%  turbostat.Pkg%pc2
> 240.00 ±  0%  +4.2% 250.14 ±  0%  turbostat.PkgWatt
>  55.36 ±  3% +16.3%  64.40 ±  2%  turbostat.RAMWatt
>  17609 ±103% -59.4%   7148 ± 72%  
> latency_stats.avg.pipe_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  63966 ±152% -68.4%  20204 ± 64%  
> latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 299681 ±123% -89.7%  30889 ± 13%  
> latency_stats.max.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%  35893 ± 10%  
> latency_stats.max.wait_on_page_bit_killable.__lock_page_or_retry.filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
>  90871 ±125% -56.2%  39835 ± 74%  
> latency_stats.sum.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>  61821 ± 22% -86.6%   8254 ± 62%  
> latency_stats.sum.sigsuspend.SyS_rt_sigsuspend.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%  59392 ±118%  
> latency_stats.sum.throttle_direct_reclaim.try_to_free_pages.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead.filemap_fault.xfs_filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault
>   0.00 ± -1%  +Inf%1549096 ± 24%  
> latency_stats.sum.wait_on_page_bit_killable.__lock_page_or_retry.filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
> 639.30 ±  8% -38.8% 391.40 ±  6%  slabinfo.RAW.active_objs
> 639.30 ±  8% -38.8% 391.40 ±  6%  slabinfo.RAW.num_objs
> 555.90 ± 14%

Re: [lkp] [huge tmpfs] d7c7d56ca6: vm-scalability.throughput -5.5% regression

2016-04-12 Thread Hugh Dickins

On Wed, 13 Apr 2016, kernel test robot wrote:

> FYI, we noticed that vm-scalability.throughput -5.5% regression on
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit d7c7d56ca61aec18e5e0cb3a64e50073c42195f7 ("huge tmpfs: avoid premature 
> exposure of new pagetable")

Very useful info, thank you.  I presume it confirms exactly what Kirill
warned me of, that doing the map_pages after instead of before the fault,
comes with a performance disadvantage.  I shall look into it, but not
immediately (and we know other reasons why that patch has to be revisited).

Hugh

> 
> 
> =
> compiler/cpufreq_governor/kconfig/rootfs/runtime/tbox_group/test/testcase:
>   
> gcc-4.9/performance/x86_64-rhel/debian-x86_64-2015-02-07.cgz/300s/lkp-hsw01/lru-file-mmap-read-rand/vm-scalability
> 
> commit: 
>   517348161d2725b8b596feb10c813bf596dc6a47
>   d7c7d56ca61aec18e5e0cb3a64e50073c42195f7
> 
> 517348161d2725b8 d7c7d56ca61aec18e5e0cb3a64 
>  -- 
>fail:runs  %reproductionfail:runs
>| | |
>1801726 ±  0%  -5.5%1702808 ±  0%  vm-scalability.throughput
> 317.89 ±  0%  +2.9% 327.15 ±  0%  vm-scalability.time.elapsed_time
> 317.89 ±  0%  +2.9% 327.15 ±  0%  
> vm-scalability.time.elapsed_time.max
> 872240 ±  4%  +8.5% 946467 ±  1%  
> vm-scalability.time.involuntary_context_switches
>   6.73e+08 ±  0% -92.5%   50568722 ±  0%  
> vm-scalability.time.major_page_faults
>2109093 ±  9% -25.8%1564815 ±  7%  
> vm-scalability.time.maximum_resident_set_size
>  37881 ±  0%+586.9% 260194 ±  0%  
> vm-scalability.time.minor_page_faults
>   5087 ±  0%  +3.7%   5277 ±  0%  
> vm-scalability.time.percent_of_cpu_this_job_got
>  16047 ±  0%  +7.5%  17252 ±  0%  vm-scalability.time.system_time
> 127.19 ±  0% -88.3%  14.93 ±  1%  vm-scalability.time.user_time
>  72572 ±  7% +56.0% 113203 ±  3%  cpuidle.C1-HSW.usage
>  9.879e+08 ±  4% -32.5%   6.67e+08 ±  8%  cpuidle.C6-HSW.time
> 605545 ±  3% -12.9% 527295 ±  1%  softirqs.RCU
> 164170 ±  7% +20.5% 197881 ±  6%  softirqs.SCHED
>2584429 ±  3% -25.5%1925241 ±  2%  vmstat.memory.free
> 252507 ±  0% +36.2% 343994 ±  0%  vmstat.system.in
>  2.852e+08 ±  5%+163.9%  7.527e+08 ±  1%  numa-numastat.node0.local_node
>  2.852e+08 ±  5%+163.9%  7.527e+08 ±  1%  numa-numastat.node0.numa_hit
>  2.876e+08 ±  6%+162.8%  7.559e+08 ±  0%  numa-numastat.node1.local_node
>  2.876e+08 ±  6%+162.8%  7.559e+08 ±  0%  numa-numastat.node1.numa_hit
>   6.73e+08 ±  0% -92.5%   50568722 ±  0%  time.major_page_faults
>2109093 ±  9% -25.8%1564815 ±  7%  time.maximum_resident_set_size
>  37881 ±  0%+586.9% 260194 ±  0%  time.minor_page_faults
> 127.19 ±  0% -88.3%  14.93 ±  1%  time.user_time
>  94.37 ±  0%  +2.0%  96.27 ±  0%  turbostat.%Busy
>   2919 ±  0%  +2.0%   2977 ±  0%  turbostat.Avg_MHz
>   5.12 ±  4% -38.7%   3.14 ±  5%  turbostat.CPU%c6
>   2.00 ± 13% -44.8%   1.10 ± 22%  turbostat.Pkg%pc2
> 240.00 ±  0%  +4.2% 250.14 ±  0%  turbostat.PkgWatt
>  55.36 ±  3% +16.3%  64.40 ±  2%  turbostat.RAMWatt
>  17609 ±103% -59.4%   7148 ± 72%  
> latency_stats.avg.pipe_write.__vfs_write.vfs_write.SyS_write.entry_SYSCALL_64_fastpath
>  63966 ±152% -68.4%  20204 ± 64%  
> latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
> 299681 ±123% -89.7%  30889 ± 13%  
> latency_stats.max.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%  35893 ± 10%  
> latency_stats.max.wait_on_page_bit_killable.__lock_page_or_retry.filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
>  90871 ±125% -56.2%  39835 ± 74%  
> latency_stats.sum.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
>  61821 ± 22% -86.6%   8254 ± 62%  
> latency_stats.sum.sigsuspend.SyS_rt_sigsuspend.entry_SYSCALL_64_fastpath
>   0.00 ± -1%  +Inf%  59392 ±118%  
> latency_stats.sum.throttle_direct_reclaim.try_to_free_pages.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead.filemap_fault.xfs_filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault
>   0.00 ± -1%  +Inf%1549096 ± 24%  
> latency_stats.sum.wait_on_page_bit_killable.__lock_page_or_retry.filemap_fault.__do_fault.do_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
> 639.30 ±  8% -38.8% 391.40 ±  6%  slabinfo.RAW.active_objs
> 639.30 ±  8% -38.8% 391.40 ±  6%  slabinfo.RAW.num_objs
> 555.90 ± 14%

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

2016-04-12 Thread Cyrill Gorcunov

On Tue, Apr 12, 2016 at 05:39:14PM -0700, Andrew Vagin wrote:
> > 
> > task = NULL always here?
> 
> No, it isn't if the loop is interrupted by break.

Yeah, managed to miss break, thanks!

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

2016-04-12 Thread Cyrill Gorcunov

On Tue, Apr 12, 2016 at 05:39:14PM -0700, Andrew Vagin wrote:
> > 
> > task = NULL always here?
> 
> No, it isn't if the loop is interrupted by break.

Yeah, managed to miss break, thanks!

Re: [PATCH] pmem: fix BUG() error in pmem.h:48 on X86_32

2016-04-12 Thread Dan Williams

On Tue, Apr 12, 2016 at 5:10 PM, Toshi Kani  wrote:
> After 'commit fc0c2028135c ("x86, pmem: use memcpy_mcsafe()
> for memcpy_from_pmem()")', probing a PMEM device hits the BUG()
> error below on X86_32 kernel.
>
>  kernel BUG at include/linux/pmem.h:48!
>
> memcpy_from_pmem() calls arch_memcpy_from_pmem(), which is
> unimplemented since CONFIG_ARCH_HAS_PMEM_API is undefined on
> X86_32.
>
> Fix the BUG() error by adding default_memcpy_from_pmem().
>
> Signed-off-by: Toshi Kani 
> Cc: Dan Williams 
> Cc: Ross Zwisler 

Whoops, I'll add a 32-bit boot test to my release criteria.  Thanks Toshi!

Re: [PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

2016-04-12 Thread Stefan Agner

On 2016-04-11 18:38, Shawn Guo wrote:
> On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
>> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
>> mixes the bus clock with the display controllers pixel clock. Tests
>> have shown that the gates in CCM_CCGR3/9 registers do not control
>> the DCU pixel clock, but only the register access clock (bus clock).
>>
>> Fix this by defining the parent clock of VF610_CLK_DCUx to be the bus
>> clock (ipg_bus).
>>
>> Since the clock has not been used far, there are no further changes
>> needed.
>>
>> Signed-off-by: Stefan Agner 
> 
> Applied 1 and 2, with updating subject prefix to be 'clk: imx: vf610: '

Thanks Shawn. Applied 3~6 in my FSL DCU tree. I guess 7~9 should go
through your tree as well?

--
Stefan


>> ---
>>  drivers/clk/imx/clk-vf610.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
>> index 0a94d96..426fde2 100644
>> --- a/drivers/clk/imx/clk-vf610.c
>> +++ b/drivers/clk/imx/clk-vf610.c
>> @@ -321,11 +321,11 @@ static void __init vf610_clocks_init(struct 
>> device_node *ccm_node)
>>  clk[VF610_CLK_DCU0_SEL] = imx_clk_mux("dcu0_sel", CCM_CSCMR1, 28, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU0_EN] = imx_clk_gate("dcu0_en", "dcu0_sel", 
>> CCM_CSCDR3, 19);
>>  clk[VF610_CLK_DCU0_DIV] = imx_clk_divider("dcu0_div", "dcu0_en", 
>> CCM_CSCDR3, 16, 3);
>> -clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "dcu0_div", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "ipg_bus", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>>  clk[VF610_CLK_DCU1_SEL] = imx_clk_mux("dcu1_sel", CCM_CSCMR1, 29, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU1_EN] = imx_clk_gate("dcu1_en", "dcu1_sel", 
>> CCM_CSCDR3, 23);
>>  clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", 
>> CCM_CSCDR3, 20, 3);
>> -clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "ipg_bus", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>>
>>  clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, 
>> esai_sels, 4);
>>  clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", 
>> CCM_CSCDR2, 30);
>> --
>> 2.7.4
>>
>>

Re: [PATCH v3 1/9] ARM: imx: clk-vf610: fix DCU clock tree

2016-04-12 Thread Stefan Agner

On 2016-04-11 18:38, Shawn Guo wrote:
> On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
>> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
>> mixes the bus clock with the display controllers pixel clock. Tests
>> have shown that the gates in CCM_CCGR3/9 registers do not control
>> the DCU pixel clock, but only the register access clock (bus clock).
>>
>> Fix this by defining the parent clock of VF610_CLK_DCUx to be the bus
>> clock (ipg_bus).
>>
>> Since the clock has not been used far, there are no further changes
>> needed.
>>
>> Signed-off-by: Stefan Agner 
> 
> Applied 1 and 2, with updating subject prefix to be 'clk: imx: vf610: '

Thanks Shawn. Applied 3~6 in my FSL DCU tree. I guess 7~9 should go
through your tree as well?

--
Stefan


>> ---
>>  drivers/clk/imx/clk-vf610.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
>> index 0a94d96..426fde2 100644
>> --- a/drivers/clk/imx/clk-vf610.c
>> +++ b/drivers/clk/imx/clk-vf610.c
>> @@ -321,11 +321,11 @@ static void __init vf610_clocks_init(struct 
>> device_node *ccm_node)
>>  clk[VF610_CLK_DCU0_SEL] = imx_clk_mux("dcu0_sel", CCM_CSCMR1, 28, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU0_EN] = imx_clk_gate("dcu0_en", "dcu0_sel", 
>> CCM_CSCDR3, 19);
>>  clk[VF610_CLK_DCU0_DIV] = imx_clk_divider("dcu0_div", "dcu0_en", 
>> CCM_CSCDR3, 16, 3);
>> -clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "dcu0_div", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU0] = imx_clk_gate2("dcu0", "ipg_bus", CCM_CCGR3, 
>> CCM_CCGRx_CGn(8));
>>  clk[VF610_CLK_DCU1_SEL] = imx_clk_mux("dcu1_sel", CCM_CSCMR1, 29, 1, 
>> dcu_sels, 2);
>>  clk[VF610_CLK_DCU1_EN] = imx_clk_gate("dcu1_en", "dcu1_sel", 
>> CCM_CSCDR3, 23);
>>  clk[VF610_CLK_DCU1_DIV] = imx_clk_divider("dcu1_div", "dcu1_en", 
>> CCM_CSCDR3, 20, 3);
>> -clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "dcu1_div", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>> +clk[VF610_CLK_DCU1] = imx_clk_gate2("dcu1", "ipg_bus", CCM_CCGR9, 
>> CCM_CCGRx_CGn(8));
>>
>>  clk[VF610_CLK_ESAI_SEL] = imx_clk_mux("esai_sel", CCM_CSCMR1, 20, 2, 
>> esai_sels, 4);
>>  clk[VF610_CLK_ESAI_EN] = imx_clk_gate("esai_en", "esai_sel", 
>> CCM_CSCDR2, 30);
>> --
>> 2.7.4
>>
>>

Re: [PATCH] pmem: fix BUG() error in pmem.h:48 on X86_32

2016-04-12 Thread Dan Williams

On Tue, Apr 12, 2016 at 5:10 PM, Toshi Kani  wrote:
> After 'commit fc0c2028135c ("x86, pmem: use memcpy_mcsafe()
> for memcpy_from_pmem()")', probing a PMEM device hits the BUG()
> error below on X86_32 kernel.
>
>  kernel BUG at include/linux/pmem.h:48!
>
> memcpy_from_pmem() calls arch_memcpy_from_pmem(), which is
> unimplemented since CONFIG_ARCH_HAS_PMEM_API is undefined on
> X86_32.
>
> Fix the BUG() error by adding default_memcpy_from_pmem().
>
> Signed-off-by: Toshi Kani 
> Cc: Dan Williams 
> Cc: Ross Zwisler 

Whoops, I'll add a 32-bit boot test to my release criteria.  Thanks Toshi!

RE: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the spi_transfer structure.

2016-04-12 Thread Lakshmi Sai Krishna Potthuri

Hi Cyrille and Mark,

>-Original Message-
>From: Cyrille Pitchen [mailto:cyrille.pitc...@atmel.com]
>Sent: Thursday, April 07, 2016 8:33 PM
>To: Lakshmi Sai Krishna Potthuri ; Michal Simek
>; Soren Brinkmann ; David
>Woodhouse ; Brian Norris
>; Mark Brown ;
>Javier Martinez Canillas ; Boris Brezillon
>; Stephen Warren
>; Geert Uytterhoeven ;
>Andrew F. Davis ; Marek Vasut ; Jagan Teki
>; Rafał Miłecki 
>Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
>s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Harini Katakam
>; Punnaiah Choudary Kalluri ;
>Anirudha Sarangi ; Lakshmi Sai Krishna Potthuri
>; R, Vignesh 
>Subject: Re: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the
>spi_transfer structure.
>
>Hi all,
>
>Le 07/04/2016 16:39, P L Sai Krishna a écrit :
>> This patch adds dummy_cycles entry in the spi_transfer structure.
>> len field in the transfer structure contains dummy bytes along with
>> actual data bytes, controllers which requires dummy bytes use len
>> field and simply Ignore the dummy_cycles field. Controllers which
>> expects dummy cycles won't work directly by using len field because
>> host driver doesn't know that len field of a particular transfer
>> includes dummy bytes or not (and also number of dummy bytes included
>> in len field). In such cases host driver use this dummy_cycles field
>> to identify the number of dummy cycles and based on that it will send
>> the required number of dummy cycles.
>
>Dummy cycles are only used with SPI NOR flashes, aren't they?

Yes, with SPI NOR flashes.

>I guess so since there is also a patch dedicated to the m25p80 driver.
>
>So why not using the spi_flash_read() API already introduced by Vignesh
>in the SPI layer?

ZynqMP GQSPI controller driver use "transfer_one" hook. Since this is generic
Controller majorly interfaced to flash devices and it might extend to NAND
flashes in future. This patch does not disturb the existing implementation of
accessing the flash or other slave devices. It adds an additional optional
feature. So there is no harm to controllers that don't need dummy cycles -
they can ignore it and still work with the existing implementation.

Regards
Sai Krishna
>
>struct spi_flash_read_message already includes a 'dummy_bytes' member.
>
>>
>> Signed-off-by: P L Sai Krishna 
>> ---
>> v2:
>>  - Changed the structure member name from dummy to dummy_cycles.
>>  - Updated the documentation of dummy_cycles.
>>  - m25p80 changes split into another patch.
>>
>>  include/linux/spi/spi.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
>> index 857a9a1..63135b3 100644
>> --- a/include/linux/spi/spi.h
>> +++ b/include/linux/spi/spi.h
>> @@ -664,6 +664,9 @@ extern void spi_res_release(struct spi_master
>*master,
>>   * @len: size of rx and tx buffers (in bytes)
>>   * @speed_hz: Select a speed other than the device default for this
>>   *  transfer. If 0 the default (from @spi_device) is used.
>> + * @dummy_cycles: number of dummy cycles. If host controller requires
>> + *  dummy cycles rather than dummy bytes which send along with Cmd
>> + *  and address then this dummy_cycles is used.
>>   * @bits_per_word: select a bits_per_word other than the device default
>>   *  for this transfer. If 0 the default (from @spi_device) is used.
>>   * @cs_change: affects chipselect after this transfer completes
>> @@ -752,6 +755,7 @@ struct spi_transfer {
>>  u8  bits_per_word;
>>  u16 delay_usecs;
>>  u32 speed_hz;
>> +u32 dummy_cycles;
>>
>>  struct list_head transfer_list;
>>  };
>>
>
>Best regards,
>
>Cyrille


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

RE: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the spi_transfer structure.

2016-04-12 Thread Lakshmi Sai Krishna Potthuri

Hi Cyrille and Mark,

>-Original Message-
>From: Cyrille Pitchen [mailto:cyrille.pitc...@atmel.com]
>Sent: Thursday, April 07, 2016 8:33 PM
>To: Lakshmi Sai Krishna Potthuri ; Michal Simek
>; Soren Brinkmann ; David
>Woodhouse ; Brian Norris
>; Mark Brown ;
>Javier Martinez Canillas ; Boris Brezillon
>; Stephen Warren
>; Geert Uytterhoeven ;
>Andrew F. Davis ; Marek Vasut ; Jagan Teki
>; Rafał Miłecki 
>Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
>s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Harini Katakam
>; Punnaiah Choudary Kalluri ;
>Anirudha Sarangi ; Lakshmi Sai Krishna Potthuri
>; R, Vignesh 
>Subject: Re: [LINUX PATCH v2 1/3] spi: Added dummy_cycle entry in the
>spi_transfer structure.
>
>Hi all,
>
>Le 07/04/2016 16:39, P L Sai Krishna a écrit :
>> This patch adds dummy_cycles entry in the spi_transfer structure.
>> len field in the transfer structure contains dummy bytes along with
>> actual data bytes, controllers which requires dummy bytes use len
>> field and simply Ignore the dummy_cycles field. Controllers which
>> expects dummy cycles won't work directly by using len field because
>> host driver doesn't know that len field of a particular transfer
>> includes dummy bytes or not (and also number of dummy bytes included
>> in len field). In such cases host driver use this dummy_cycles field
>> to identify the number of dummy cycles and based on that it will send
>> the required number of dummy cycles.
>
>Dummy cycles are only used with SPI NOR flashes, aren't they?

Yes, with SPI NOR flashes.

>I guess so since there is also a patch dedicated to the m25p80 driver.
>
>So why not using the spi_flash_read() API already introduced by Vignesh
>in the SPI layer?

ZynqMP GQSPI controller driver use "transfer_one" hook. Since this is generic
Controller majorly interfaced to flash devices and it might extend to NAND
flashes in future. This patch does not disturb the existing implementation of
accessing the flash or other slave devices. It adds an additional optional
feature. So there is no harm to controllers that don't need dummy cycles -
they can ignore it and still work with the existing implementation.

Regards
Sai Krishna
>
>struct spi_flash_read_message already includes a 'dummy_bytes' member.
>
>>
>> Signed-off-by: P L Sai Krishna 
>> ---
>> v2:
>>  - Changed the structure member name from dummy to dummy_cycles.
>>  - Updated the documentation of dummy_cycles.
>>  - m25p80 changes split into another patch.
>>
>>  include/linux/spi/spi.h | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
>> index 857a9a1..63135b3 100644
>> --- a/include/linux/spi/spi.h
>> +++ b/include/linux/spi/spi.h
>> @@ -664,6 +664,9 @@ extern void spi_res_release(struct spi_master
>*master,
>>   * @len: size of rx and tx buffers (in bytes)
>>   * @speed_hz: Select a speed other than the device default for this
>>   *  transfer. If 0 the default (from @spi_device) is used.
>> + * @dummy_cycles: number of dummy cycles. If host controller requires
>> + *  dummy cycles rather than dummy bytes which send along with Cmd
>> + *  and address then this dummy_cycles is used.
>>   * @bits_per_word: select a bits_per_word other than the device default
>>   *  for this transfer. If 0 the default (from @spi_device) is used.
>>   * @cs_change: affects chipselect after this transfer completes
>> @@ -752,6 +755,7 @@ struct spi_transfer {
>>  u8  bits_per_word;
>>  u16 delay_usecs;
>>  u32 speed_hz;
>> +u32 dummy_cycles;
>>
>>  struct list_head transfer_list;
>>  };
>>
>
>Best regards,
>
>Cyrille


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

[PATCH v5 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

2016-04-12 Thread Kedareswara rao Appana

Added the driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. The dma controller supports memory to memory and
memory to I/O buffer transfers.

Signed-off-by: Punnaiah Choudary Kalluri 
Signed-off-by: Kedareswara rao Appana 
---
Changes in v5:
- Removed in_interrupt check from the tasklet cleanup as
  suggested by the vinod/lars.
Changes in v4:
- Modified the defines to start with ZYNQMP_DMA perfix
- Changed the zynqmp_dma_alloc_chan_resources to return number of
  allocated descriptors
- Changed the zynqmp_dma_device variable name
- Released the locks before calling user callback
- freeup irq in zynqmp_dma_chan_remove function.
Changes in v3:
- Modified the zynqmp_dma_chan_is_idle function return type to bool
Changes in v2:
- Corrected the function header documentation
- Framework expects bus-width value in bytes. so, fixed it
- Removed magic numbers for bus-width

 drivers/dma/Kconfig |5 +
 drivers/dma/xilinx/Makefile |1 +
 drivers/dma/xilinx/zynqmp_dma.c | 1244 +++
 3 files changed, 1250 insertions(+)
 create mode 100644 drivers/dma/xilinx/zynqmp_dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d96d87c..dd6a38c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -527,6 +527,11 @@ config ZX_DMA
help
  Support the DMA engine for ZTE ZX296702 platform devices.
 
+config XILINX_ZYNQMP_DMA
+   tristate "Xilinx ZynqMP DMA Engine"
+   select DMA_ENGINE
+   help
+ Enable support for Xilinx ZynqMP DMA controller.
 
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..95469dc 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
new file mode 100644
index 000..7b11895
--- /dev/null
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -0,0 +1,1244 @@
+/*
+ * DMA driver for Xilinx ZynqMP DMA Engine
+ *
+ * Copyright (C) 2016 Xilinx, Inc. All rights reserved.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define ZYNQMP_DMA_ISR 0x100
+#define ZYNQMP_DMA_IMR 0x104
+#define ZYNQMP_DMA_IER 0x108
+#define ZYNQMP_DMA_IDS 0x10C
+#define ZYNQMP_DMA_CTRL0   0x110
+#define ZYNQMP_DMA_CTRL1   0x114
+#define ZYNQMP_DMA_DATA_ATTR   0x120
+#define ZYNQMP_DMA_DSCR_ATTR   0x124
+#define ZYNQMP_DMA_SRC_DSCR_WRD0   0x128
+#define ZYNQMP_DMA_SRC_DSCR_WRD1   0x12C
+#define ZYNQMP_DMA_SRC_DSCR_WRD2   0x130
+#define ZYNQMP_DMA_SRC_DSCR_WRD3   0x134
+#define ZYNQMP_DMA_DST_DSCR_WRD0   0x138
+#define ZYNQMP_DMA_DST_DSCR_WRD1   0x13C
+#define ZYNQMP_DMA_DST_DSCR_WRD2   0x140
+#define ZYNQMP_DMA_DST_DSCR_WRD3   0x144
+#define ZYNQMP_DMA_SRC_START_LSB   0x158
+#define ZYNQMP_DMA_SRC_START_MSB   0x15C
+#define ZYNQMP_DMA_DST_START_LSB   0x160
+#define ZYNQMP_DMA_DST_START_MSB   0x164
+#define ZYNQMP_DMA_RATE_CTRL   0x18C
+#define ZYNQMP_DMA_IRQ_SRC_ACCT0x190
+#define ZYNQMP_DMA_IRQ_DST_ACCT0x194
+#define ZYNQMP_DMA_CTRL2   0x200
+
+/* Interrupt registers bit field definitions */
+#define ZYNQMP_DMA_DONEBIT(10)
+#define ZYNQMP_DMA_AXI_WR_DATA BIT(9)
+#define ZYNQMP_DMA_AXI_RD_DATA BIT(8)
+#define ZYNQMP_DMA_AXI_RD_DST_DSCR BIT(7)
+#define ZYNQMP_DMA_AXI_RD_SRC_DSCR BIT(6)
+#define ZYNQMP_DMA_IRQ_DST_ACCT_ERRBIT(5)
+#define ZYNQMP_DMA_IRQ_SRC_ACCT_ERRBIT(4)
+#define ZYNQMP_DMA_BYTE_CNT_OVRFL  BIT(3)
+#define ZYNQMP_DMA_DST_DSCR_DONE   BIT(2)
+#define ZYNQMP_DMA_INV_APB BIT(0)
+
+/* Control 0 register bit field definitions */
+#define ZYNQMP_DMA_OVR_FETCH   BIT(7)
+#define ZYNQMP_DMA_POINT_TYPE_SG   BIT(6)
+#define ZYNQMP_DMA_RATE_CTRL_ENBIT(3)
+
+/* Control 1 register bit field definitions */
+#define ZYNQMP_DMA_SRC_ISSUE   GENMASK(4, 0)
+
+/* Data Attribute register bit field definitions */
+#define ZYNQMP_DMA_ARBURST GENMASK(27, 26)
+#define ZYNQMP_DMA_ARCACHE GENMASK(25, 22)
+#define ZYNQMP_DMA_ARCACHE_OFST22
+#define ZYNQMP_DMA_ARQOS   GENMASK(21, 18)
+#define ZYNQMP_DMA_ARQOS_OFST  18
+#define

[PATCH v5 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support

2016-04-12 Thread Kedareswara rao Appana

Added the driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. The dma controller supports memory to memory and
memory to I/O buffer transfers.

Signed-off-by: Punnaiah Choudary Kalluri 
Signed-off-by: Kedareswara rao Appana 
---
Changes in v5:
- Removed in_interrupt check from the tasklet cleanup as
  suggested by the vinod/lars.
Changes in v4:
- Modified the defines to start with ZYNQMP_DMA perfix
- Changed the zynqmp_dma_alloc_chan_resources to return number of
  allocated descriptors
- Changed the zynqmp_dma_device variable name
- Released the locks before calling user callback
- freeup irq in zynqmp_dma_chan_remove function.
Changes in v3:
- Modified the zynqmp_dma_chan_is_idle function return type to bool
Changes in v2:
- Corrected the function header documentation
- Framework expects bus-width value in bytes. so, fixed it
- Removed magic numbers for bus-width

 drivers/dma/Kconfig |5 +
 drivers/dma/xilinx/Makefile |1 +
 drivers/dma/xilinx/zynqmp_dma.c | 1244 +++
 3 files changed, 1250 insertions(+)
 create mode 100644 drivers/dma/xilinx/zynqmp_dma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d96d87c..dd6a38c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -527,6 +527,11 @@ config ZX_DMA
help
  Support the DMA engine for ZTE ZX296702 platform devices.
 
+config XILINX_ZYNQMP_DMA
+   tristate "Xilinx ZynqMP DMA Engine"
+   select DMA_ENGINE
+   help
+ Enable support for Xilinx ZynqMP DMA controller.
 
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index 3c4e9f2..95469dc 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o
+obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c
new file mode 100644
index 000..7b11895
--- /dev/null
+++ b/drivers/dma/xilinx/zynqmp_dma.c
@@ -0,0 +1,1244 @@
+/*
+ * DMA driver for Xilinx ZynqMP DMA Engine
+ *
+ * Copyright (C) 2016 Xilinx, Inc. All rights reserved.
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+
+/* Register Offsets */
+#define ZYNQMP_DMA_ISR 0x100
+#define ZYNQMP_DMA_IMR 0x104
+#define ZYNQMP_DMA_IER 0x108
+#define ZYNQMP_DMA_IDS 0x10C
+#define ZYNQMP_DMA_CTRL0   0x110
+#define ZYNQMP_DMA_CTRL1   0x114
+#define ZYNQMP_DMA_DATA_ATTR   0x120
+#define ZYNQMP_DMA_DSCR_ATTR   0x124
+#define ZYNQMP_DMA_SRC_DSCR_WRD0   0x128
+#define ZYNQMP_DMA_SRC_DSCR_WRD1   0x12C
+#define ZYNQMP_DMA_SRC_DSCR_WRD2   0x130
+#define ZYNQMP_DMA_SRC_DSCR_WRD3   0x134
+#define ZYNQMP_DMA_DST_DSCR_WRD0   0x138
+#define ZYNQMP_DMA_DST_DSCR_WRD1   0x13C
+#define ZYNQMP_DMA_DST_DSCR_WRD2   0x140
+#define ZYNQMP_DMA_DST_DSCR_WRD3   0x144
+#define ZYNQMP_DMA_SRC_START_LSB   0x158
+#define ZYNQMP_DMA_SRC_START_MSB   0x15C
+#define ZYNQMP_DMA_DST_START_LSB   0x160
+#define ZYNQMP_DMA_DST_START_MSB   0x164
+#define ZYNQMP_DMA_RATE_CTRL   0x18C
+#define ZYNQMP_DMA_IRQ_SRC_ACCT0x190
+#define ZYNQMP_DMA_IRQ_DST_ACCT0x194
+#define ZYNQMP_DMA_CTRL2   0x200
+
+/* Interrupt registers bit field definitions */
+#define ZYNQMP_DMA_DONEBIT(10)
+#define ZYNQMP_DMA_AXI_WR_DATA BIT(9)
+#define ZYNQMP_DMA_AXI_RD_DATA BIT(8)
+#define ZYNQMP_DMA_AXI_RD_DST_DSCR BIT(7)
+#define ZYNQMP_DMA_AXI_RD_SRC_DSCR BIT(6)
+#define ZYNQMP_DMA_IRQ_DST_ACCT_ERRBIT(5)
+#define ZYNQMP_DMA_IRQ_SRC_ACCT_ERRBIT(4)
+#define ZYNQMP_DMA_BYTE_CNT_OVRFL  BIT(3)
+#define ZYNQMP_DMA_DST_DSCR_DONE   BIT(2)
+#define ZYNQMP_DMA_INV_APB BIT(0)
+
+/* Control 0 register bit field definitions */
+#define ZYNQMP_DMA_OVR_FETCH   BIT(7)
+#define ZYNQMP_DMA_POINT_TYPE_SG   BIT(6)
+#define ZYNQMP_DMA_RATE_CTRL_ENBIT(3)
+
+/* Control 1 register bit field definitions */
+#define ZYNQMP_DMA_SRC_ISSUE   GENMASK(4, 0)
+
+/* Data Attribute register bit field definitions */
+#define ZYNQMP_DMA_ARBURST GENMASK(27, 26)
+#define ZYNQMP_DMA_ARCACHE GENMASK(25, 22)
+#define ZYNQMP_DMA_ARCACHE_OFST22
+#define ZYNQMP_DMA_ARQOS   GENMASK(21, 18)
+#define ZYNQMP_DMA_ARQOS_OFST  18
+#define ZYNQMP_DMA_ARLEN   GENMASK(17,

[PATCH v5 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

2016-04-12 Thread Kedareswara rao Appana

Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.

Signed-off-by: Punnaiah Choudary Kalluri 
Signed-off-by: Kedareswara rao Appana 
---
Changes in v5:
- Use dma-coherent flag for coherent transfers as suggested by rob.
- Removed unnecessary properties from binding doc as suggested by Rob.
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None.

 .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..4ad0aea40
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,50 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible   : Should be "xlnx,zynqmp-dma-1.0"
+- reg  : Memory map for gdma/adma module access.
+- interrupt-parent : Interrupt controller the interrupt is routed through
+- interrupts   : Should contain DMA channel interrupt.
+- xlnx,bus-width   : Axi buswidth in bits. Should contain 128 or 64
+- clock-names  : List of input clocks "clk_main", "clk_apb"
+ (see clock bindings for details)
+
+Optional properties:
+- xlnx,include-sg  : Indicates the controller to operate in simple or
+ scatter gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles 
for
+ source AXI transaction
+- xlnx,overfetch   : Tells whether the channel is allowed to over
+ fetch the data
+- xlnx,src-issue   : Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cache  : AXI cache bits to be used for descriptor fetch
+- xlnx,src-axi-cache   : AXI cache bits to be used for data read
+- xlnx,dst-axi-cache   : AXI cache bits to be used for data write
+- xlnx,src-burst-len   : AXI length for data read. Support only power of
+ 2 values.
+- xlnx,dst-burst-len   : AXI length for data write. Support only power of
+ 2 values.
+- dma-coherent : Present if dma operations are coherent.
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+   compatible = "xlnx,zynqmp-dma-1.0";
+   reg = <0x0 0xFD50 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <0 117 4>;
+   clock-names = "clk_main", "clk_apb";
+   xlnx,bus-width = <128>;
+   xlnx,include-sg;
+   xlnx,overfetch;
+   dma-coherent;
+   xlnx,ratectrl = <0>;
+   xlnx,src-issue = <16>;
+   xlnx,desc-axi-cache = <0xFF>;
+   xlnx,src-axi-cache = <0xFF>;
+   xlnx,dst-axi-cache = <0xFF>;
+   xlnx,src-burst-len = <4>;
+   xlnx,dst-burst-len = <4>;
+};
-- 
2.1.2

[PATCH v5 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

2016-04-12 Thread Kedareswara rao Appana

Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.

Signed-off-by: Punnaiah Choudary Kalluri 
Signed-off-by: Kedareswara rao Appana 
---
Changes in v5:
- Use dma-coherent flag for coherent transfers as suggested by rob.
- Removed unnecessary properties from binding doc as suggested by Rob.
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None.

 .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt

diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..4ad0aea40
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,50 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible   : Should be "xlnx,zynqmp-dma-1.0"
+- reg  : Memory map for gdma/adma module access.
+- interrupt-parent : Interrupt controller the interrupt is routed through
+- interrupts   : Should contain DMA channel interrupt.
+- xlnx,bus-width   : Axi buswidth in bits. Should contain 128 or 64
+- clock-names  : List of input clocks "clk_main", "clk_apb"
+ (see clock bindings for details)
+
+Optional properties:
+- xlnx,include-sg  : Indicates the controller to operate in simple or
+ scatter gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles 
for
+ source AXI transaction
+- xlnx,overfetch   : Tells whether the channel is allowed to over
+ fetch the data
+- xlnx,src-issue   : Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cache  : AXI cache bits to be used for descriptor fetch
+- xlnx,src-axi-cache   : AXI cache bits to be used for data read
+- xlnx,dst-axi-cache   : AXI cache bits to be used for data write
+- xlnx,src-burst-len   : AXI length for data read. Support only power of
+ 2 values.
+- xlnx,dst-burst-len   : AXI length for data write. Support only power of
+ 2 values.
+- dma-coherent : Present if dma operations are coherent.
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+   compatible = "xlnx,zynqmp-dma-1.0";
+   reg = <0x0 0xFD50 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <0 117 4>;
+   clock-names = "clk_main", "clk_apb";
+   xlnx,bus-width = <128>;
+   xlnx,include-sg;
+   xlnx,overfetch;
+   dma-coherent;
+   xlnx,ratectrl = <0>;
+   xlnx,src-issue = <16>;
+   xlnx,desc-axi-cache = <0xFF>;
+   xlnx,src-axi-cache = <0xFF>;
+   xlnx,dst-axi-cache = <0xFF>;
+   xlnx,src-burst-len = <4>;
+   xlnx,dst-burst-len = <4>;
+};
-- 
2.1.2

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

2016-04-12 Thread Michael Ellerman

On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:
> On 07/04/2016 23:49, Michael Ellerman wrote:
> > On 7 April 2016 7:23:46 pm AEST, Laurent Dufour 
> >  wrote:
> > > This series is required to handle TM state in CRIU.
> > > Is there a chance to get it upstream soon ?
> > 
> > We were waiting on the gdb support to make sure it had some testing. If 
> > it's working for CRIU that would be a good data point, have you actually 
> > tested it with CRIU?
> 
> I just started integrating it in CRIU, my basic tests didn't report any
> issue with the new ptrace API, but I can't state that it is bug free ;)

Sure. But if it's working for CRIU that's at least postive :)

cheers

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

2016-04-12 Thread Michael Ellerman

On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:
> On 07/04/2016 23:49, Michael Ellerman wrote:
> > On 7 April 2016 7:23:46 pm AEST, Laurent Dufour 
> >  wrote:
> > > This series is required to handle TM state in CRIU.
> > > Is there a chance to get it upstream soon ?
> > 
> > We were waiting on the gdb support to make sure it had some testing. If 
> > it's working for CRIU that would be a good data point, have you actually 
> > tested it with CRIU?
> 
> I just started integrating it in CRIU, my basic tests didn't report any
> issue with the new ptrace API, but I can't state that it is bug free ;)

Sure. But if it's working for CRIU that's at least postive :)

cheers

drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded semicolon

2016-04-12 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1c74a7f812b135d3df41d7c3671b647aed6467bf
commit: 39b7e6e547ffca0b42a29df5a213f5bf3a19af0b drm/nouveau/nvbios/iccsense: 
add parsing of the SENSE table
date:   4 weeks ago


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded 
>> semicolon

Please review and possibly fold the followup patch.

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

[PATCH] drm/nouveau/nvbios/iccsense: fix semicolon.cocci warnings

2016-04-12 Thread kbuild test robot

drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Martin Peres 
Signed-off-by: Fengguang Wu 
---

 iccsense.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c
@@ -93,7 +93,7 @@ nvbios_iccsense_parse(struct nvkm_bios *
rail->resistor_mohm = nvbios_rd08(bios, entry + 0x5);
rail->rail = nvbios_rd08(bios, entry + 0x6);
break;
-   };
+   }
}
 
return 0;

[PATCH] drm/nouveau/nvbios/iccsense: fix semicolon.cocci warnings

2016-04-12 Thread kbuild test robot

drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Martin Peres 
Signed-off-by: Fengguang Wu 
---

 iccsense.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c
@@ -93,7 +93,7 @@ nvbios_iccsense_parse(struct nvkm_bios *
rail->resistor_mohm = nvbios_rd08(bios, entry + 0x5);
rail->rail = nvbios_rd08(bios, entry + 0x6);
break;
-   };
+   }
}
 
return 0;

drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded semicolon

2016-04-12 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1c74a7f812b135d3df41d7c3671b647aed6467bf
commit: 39b7e6e547ffca0b42a29df5a213f5bf3a19af0b drm/nouveau/nvbios/iccsense: 
add parsing of the SENSE table
date:   4 weeks ago


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/nouveau/nvkm/subdev/bios/iccsense.c:96:3-4: Unneeded 
>> semicolon

Please review and possibly fold the followup patch.

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

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 2:15 PM, Mark Brown  wrote:
> On Thu, Apr 07, 2016 at 11:24:00PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, April 06, 2016 11:39:27 AM Mark Rutland wrote:
>
>> > The ACPI model implies FW-driven pinctrl management, so if we're going to 
>> > put
>> > the OS in direct control of pinctrl, we have to make clear what 
>> > expectation FW
>> > and OS can have.
>
>> Well, orthodox ACPI people from the Windows camp would definitely agree with 
>> you,
>> but I'm not one of them, so let me play a devil's advocate for a while. :-)
>
>> IMO, exposing anything in the ACPI tables without explicitly saying "but you
>> should not touch that", eg by defining an operation region covering it or 
>> similar,
>> is equivalent to giving the OS a license to play with that thing as it 
>> wishes.
>
>> Therefore I would regard exposing pin control information in cases when the
>> OS is not allowed to use it to its fit as a firmware bug.
>
> This is something where it seems like it would be very easy for people
> to end up relying on current OS behaviour even if that only happened
> through accident rather than design.  You might assume that such
> behaviour is a bug but that may not be obvious to the firmware author if
> the OS behaviour makes sense to them.

If the OS started to support that interface, it would need to
guarantee consistent behavior with respect to it going forward.

It would be an interface for interacting with firmware, so it is not
much different from an interface to user space as far as the stability
rules go.  Which may be a reason for refusing to support it in the
first place if the OS is not willing to make such a guarantee.

> There may also be some expectation on the part of firmware that the OS
> will do some management of the pins even for devices that it's not
> actively working with (put them in an idle mode for example).
>
>> Now, the question in this patch series is how to expose things and not when 
>> to
>> do that.  It adds support for a specific method of exposing information to 
>> the
>> OS, but should it be concerned about the possible consequences of 
>> inappropriate
>> use of that method by firmware?
>
> The other issue here is that if (as Octavian mentioned) there are
> ongoing discussions within ASWG on producing an actual spec for this it
> doesn't seem great that we'd just go and do something completely
> different rather than trying to make sure that the spec works well.  Or
> if there isn't any spec work then writing one there for other OSs to
> pick up if they like.  This seems like it'd make us much better
> community players.

Agreed.  I actually asked Octavian to look at the other proposal and
see if/how that could be used to address the use case in question
and/or possibly extended to cover it.

Thanks,
Rafael

Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 2:15 PM, Mark Brown  wrote:
> On Thu, Apr 07, 2016 at 11:24:00PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, April 06, 2016 11:39:27 AM Mark Rutland wrote:
>
>> > The ACPI model implies FW-driven pinctrl management, so if we're going to 
>> > put
>> > the OS in direct control of pinctrl, we have to make clear what 
>> > expectation FW
>> > and OS can have.
>
>> Well, orthodox ACPI people from the Windows camp would definitely agree with 
>> you,
>> but I'm not one of them, so let me play a devil's advocate for a while. :-)
>
>> IMO, exposing anything in the ACPI tables without explicitly saying "but you
>> should not touch that", eg by defining an operation region covering it or 
>> similar,
>> is equivalent to giving the OS a license to play with that thing as it 
>> wishes.
>
>> Therefore I would regard exposing pin control information in cases when the
>> OS is not allowed to use it to its fit as a firmware bug.
>
> This is something where it seems like it would be very easy for people
> to end up relying on current OS behaviour even if that only happened
> through accident rather than design.  You might assume that such
> behaviour is a bug but that may not be obvious to the firmware author if
> the OS behaviour makes sense to them.

If the OS started to support that interface, it would need to
guarantee consistent behavior with respect to it going forward.

It would be an interface for interacting with firmware, so it is not
much different from an interface to user space as far as the stability
rules go.  Which may be a reason for refusing to support it in the
first place if the OS is not willing to make such a guarantee.

> There may also be some expectation on the part of firmware that the OS
> will do some management of the pins even for devices that it's not
> actively working with (put them in an idle mode for example).
>
>> Now, the question in this patch series is how to expose things and not when 
>> to
>> do that.  It adds support for a specific method of exposing information to 
>> the
>> OS, but should it be concerned about the possible consequences of 
>> inappropriate
>> use of that method by firmware?
>
> The other issue here is that if (as Octavian mentioned) there are
> ongoing discussions within ASWG on producing an actual spec for this it
> doesn't seem great that we'd just go and do something completely
> different rather than trying to make sure that the spec works well.  Or
> if there isn't any spec work then writing one there for other OSs to
> pick up if they like.  This seems like it'd make us much better
> community players.

Agreed.  I actually asked Octavian to look at the other proposal and
see if/how that could be used to address the use case in question
and/or possibly extended to cover it.

Thanks,
Rafael

Re: [PATCH 2/6] cifs: merge the hash calculation helpers

2016-04-12 Thread Shirish Pargaonkar

Looks correct.
Tested with -o vers=1.0, -o vers=2.0, and -o vers=2.1.
Will test using mount option vers=3.0 as soon as I find a server.

Reviewed-by: Shirish Pargaonkar 
Tested-by: Shirish Pargaonkar 

On Sat, Apr 9, 2016 at 3:50 PM, Al Viro  wrote:
> three practically identical copies...
>
> Signed-off-by: Al Viro 
> ---
>  fs/cifs/cifsencrypt.c   |  97 ---
>  fs/cifs/cifsproto.h |   3 ++
>  fs/cifs/smb2transport.c | 107 
> +---
>  3 files changed, 67 insertions(+), 140 deletions(-)
>
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index 4897dac..6aeb8d4 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -66,45 +66,15 @@ cifs_crypto_shash_md5_allocate(struct TCP_Server_Info 
> *server)
> return 0;
>  }
>
> -/*
> - * Calculate and return the CIFS signature based on the mac key and SMB PDU.
> - * The 16 byte signature must be allocated by the caller. Note we only use 
> the
> - * 1st eight bytes and that the smb header signature field on input contains
> - * the sequence number before this function is called. Also, this function
> - * should be called with the server->srv_mutex held.
> - */
> -static int cifs_calc_signature(struct smb_rqst *rqst,
> -   struct TCP_Server_Info *server, char *signature)
> +int __cifs_calc_signature(struct smb_rqst *rqst,
> +   struct TCP_Server_Info *server, char *signature,
> +   struct shash_desc *shash)
>  {
> int i;
> int rc;
> struct kvec *iov = rqst->rq_iov;
> int n_vec = rqst->rq_nvec;
>
> -   if (iov == NULL || signature == NULL || server == NULL)
> -   return -EINVAL;
> -
> -   if (!server->secmech.sdescmd5) {
> -   rc = cifs_crypto_shash_md5_allocate(server);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Can't alloc md5 crypto\n", 
> __func__);
> -   return -1;
> -   }
> -   }
> -
> -   rc = crypto_shash_init(>secmech.sdescmd5->shash);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Could not init md5\n", __func__);
> -   return rc;
> -   }
> -
> -   rc = crypto_shash_update(>secmech.sdescmd5->shash,
> -   server->session_key.response, server->session_key.len);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Could not update with response\n", 
> __func__);
> -   return rc;
> -   }
> -
> for (i = 0; i < n_vec; i++) {
> if (iov[i].iov_len == 0)
> continue;
> @@ -117,12 +87,10 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
> if (i == 0) {
> if (iov[0].iov_len <= 8) /* cmd field at offset 9 */
> break; /* nothing to sign or corrupt header */
> -   rc =
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> +   rc = crypto_shash_update(shash,
> iov[i].iov_base + 4, iov[i].iov_len - 4);
> } else {
> -   rc =
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> +   rc = crypto_shash_update(shash,
> iov[i].iov_base, iov[i].iov_len);
> }
> if (rc) {
> @@ -134,21 +102,64 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
>
> /* now hash over the rq_pages array */
> for (i = 0; i < rqst->rq_npages; i++) {
> -   struct kvec p_iov;
> +   void *kaddr = kmap(rqst->rq_pages[i]);
> +   size_t len = rqst->rq_pagesz;
> +
> +   if (i == rqst->rq_npages - 1)
> +   len = rqst->rq_tailsz;
> +
> +   crypto_shash_update(shash, kaddr, len);
>
> -   cifs_rqst_page_to_kvec(rqst, i, _iov);
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> -   p_iov.iov_base, p_iov.iov_len);
> kunmap(rqst->rq_pages[i]);
> }
>
> -   rc = crypto_shash_final(>secmech.sdescmd5->shash, signature);
> +   rc = crypto_shash_final(shash, signature);
> if (rc)
> -   cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
> +   cifs_dbg(VFS, "%s: Could not generate hash\n", __func__);
>
> return rc;
>  }
>
> +/*
> + * Calculate and return the CIFS signature based on the mac key and SMB PDU.
> + * The 16 byte signature must be allocated by the caller. Note we only use 
> the
> + * 1st eight bytes and that the smb header signature field on input contains
> + * the sequence number before this function is called. Also, this function
> + * should

Re: [PATCH 2/6] cifs: merge the hash calculation helpers

2016-04-12 Thread Shirish Pargaonkar

Looks correct.
Tested with -o vers=1.0, -o vers=2.0, and -o vers=2.1.
Will test using mount option vers=3.0 as soon as I find a server.

Reviewed-by: Shirish Pargaonkar 
Tested-by: Shirish Pargaonkar 

On Sat, Apr 9, 2016 at 3:50 PM, Al Viro  wrote:
> three practically identical copies...
>
> Signed-off-by: Al Viro 
> ---
>  fs/cifs/cifsencrypt.c   |  97 ---
>  fs/cifs/cifsproto.h |   3 ++
>  fs/cifs/smb2transport.c | 107 
> +---
>  3 files changed, 67 insertions(+), 140 deletions(-)
>
> diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c
> index 4897dac..6aeb8d4 100644
> --- a/fs/cifs/cifsencrypt.c
> +++ b/fs/cifs/cifsencrypt.c
> @@ -66,45 +66,15 @@ cifs_crypto_shash_md5_allocate(struct TCP_Server_Info 
> *server)
> return 0;
>  }
>
> -/*
> - * Calculate and return the CIFS signature based on the mac key and SMB PDU.
> - * The 16 byte signature must be allocated by the caller. Note we only use 
> the
> - * 1st eight bytes and that the smb header signature field on input contains
> - * the sequence number before this function is called. Also, this function
> - * should be called with the server->srv_mutex held.
> - */
> -static int cifs_calc_signature(struct smb_rqst *rqst,
> -   struct TCP_Server_Info *server, char *signature)
> +int __cifs_calc_signature(struct smb_rqst *rqst,
> +   struct TCP_Server_Info *server, char *signature,
> +   struct shash_desc *shash)
>  {
> int i;
> int rc;
> struct kvec *iov = rqst->rq_iov;
> int n_vec = rqst->rq_nvec;
>
> -   if (iov == NULL || signature == NULL || server == NULL)
> -   return -EINVAL;
> -
> -   if (!server->secmech.sdescmd5) {
> -   rc = cifs_crypto_shash_md5_allocate(server);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Can't alloc md5 crypto\n", 
> __func__);
> -   return -1;
> -   }
> -   }
> -
> -   rc = crypto_shash_init(>secmech.sdescmd5->shash);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Could not init md5\n", __func__);
> -   return rc;
> -   }
> -
> -   rc = crypto_shash_update(>secmech.sdescmd5->shash,
> -   server->session_key.response, server->session_key.len);
> -   if (rc) {
> -   cifs_dbg(VFS, "%s: Could not update with response\n", 
> __func__);
> -   return rc;
> -   }
> -
> for (i = 0; i < n_vec; i++) {
> if (iov[i].iov_len == 0)
> continue;
> @@ -117,12 +87,10 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
> if (i == 0) {
> if (iov[0].iov_len <= 8) /* cmd field at offset 9 */
> break; /* nothing to sign or corrupt header */
> -   rc =
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> +   rc = crypto_shash_update(shash,
> iov[i].iov_base + 4, iov[i].iov_len - 4);
> } else {
> -   rc =
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> +   rc = crypto_shash_update(shash,
> iov[i].iov_base, iov[i].iov_len);
> }
> if (rc) {
> @@ -134,21 +102,64 @@ static int cifs_calc_signature(struct smb_rqst *rqst,
>
> /* now hash over the rq_pages array */
> for (i = 0; i < rqst->rq_npages; i++) {
> -   struct kvec p_iov;
> +   void *kaddr = kmap(rqst->rq_pages[i]);
> +   size_t len = rqst->rq_pagesz;
> +
> +   if (i == rqst->rq_npages - 1)
> +   len = rqst->rq_tailsz;
> +
> +   crypto_shash_update(shash, kaddr, len);
>
> -   cifs_rqst_page_to_kvec(rqst, i, _iov);
> -   crypto_shash_update(>secmech.sdescmd5->shash,
> -   p_iov.iov_base, p_iov.iov_len);
> kunmap(rqst->rq_pages[i]);
> }
>
> -   rc = crypto_shash_final(>secmech.sdescmd5->shash, signature);
> +   rc = crypto_shash_final(shash, signature);
> if (rc)
> -   cifs_dbg(VFS, "%s: Could not generate md5 hash\n", __func__);
> +   cifs_dbg(VFS, "%s: Could not generate hash\n", __func__);
>
> return rc;
>  }
>
> +/*
> + * Calculate and return the CIFS signature based on the mac key and SMB PDU.
> + * The 16 byte signature must be allocated by the caller. Note we only use 
> the
> + * 1st eight bytes and that the smb header signature field on input contains
> + * the sequence number before this function is called. Also, this function
> + * should be called with the server->srv_mutex held.
> + */
> +static int cifs_calc_signature(struct smb_rqst *rqst,

linux-next: Tree for Apr 13

2016-04-12 Thread Stephen Rothwell

Hi all,

Changes since 20160412:

The keys tree gained a conflict against the crypto tree.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 3274
 3208 files changed, 125941 insertions(+), 78193 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1c74a7f812b1 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (0dee6c82c2aa ARC: [plat-axs103] Enable loop block 
devices)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (1ecf689013b5 devlink: add missing install of header)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (adcdd0d5a1cb ALSA: usb-audio: Skip volume 
controls triggers hangup on Dell USB Dock)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (87243deb8867 debugfs: Make 
automount point inodes permanently empty)
Merging tty.current/tty-linus (bf1620068911 Linux 4.6-rc3)
Merging usb.current/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)

linux-next: Tree for Apr 13

2016-04-12 Thread Stephen Rothwell

Hi all,

Changes since 20160412:

The keys tree gained a conflict against the crypto tree.

The akpm-current tree still had its build failure for which I applied
a patch.

Non-merge commits (relative to Linus' tree): 3274
 3208 files changed, 125941 insertions(+), 78193 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1c74a7f812b1 Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (0dee6c82c2aa ARC: [plat-axs103] Enable loop block 
devices)
Merging arm-current/fixes (208fae5c3b94 ARM: 8550/1: protect idiv patching 
against undefined gcc behavior)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (1ecf689013b5 devlink: add missing install of header)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (adcdd0d5a1cb ALSA: usb-audio: Skip volume 
controls triggers hangup on Dell USB Dock)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (87243deb8867 debugfs: Make 
automount point inodes permanently empty)
Merging tty.current/tty-linus (bf1620068911 Linux 4.6-rc3)
Merging usb.current/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-gadget-fixes/fixes (adf9a3ab90eb usb: dwc3: keystone: drop dma_mask 
configuration)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (053f78d35995 Merge tag 
'lkdtm-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux 
into char-misc-linus)
Merging input-current/for-linus (7eb5ca09e48e Input: clarify we want 
BTN_TOOL_ on proximity)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)

Не увидел ни вывески, ни штендера на доме

2016-04-12 Thread Михаил Ермаков

Добрый день!

Я не так давно проходил мимо здания где вы находитесь, и обратил внимание, что 
на здании нет вывески Вашей организации.

Я профессионально занимаюсь изготовлением и установкой вывесок (у нас 
собственная мастерская).

Размещение рекламных вывесок в Вашем здании возможно! Поток клиентов с улицы - 
быстро окупит вывеску.

Возможны варианты:
- Вывеска - от 5500 рублей
- Объемные буквы от 85 рублей см
- Световые короба 9000 рублей
- И другие виды рекламных конструкций.

По вывескам много вариантов - от реально недорогих до серьезных.

Если принципиальный интерес у Вас есть - просто напишите - какого размера и 
какого типа вывеску Вам хотелось бы - я смогу рассчитать стоимость изготовления 
и монтаж. 

С уважением, Михаил.

Не увидел ни вывески, ни штендера на доме

2016-04-12 Thread Михаил Ермаков

Добрый день!

Я не так давно проходил мимо здания где вы находитесь, и обратил внимание, что 
на здании нет вывески Вашей организации.

Я профессионально занимаюсь изготовлением и установкой вывесок (у нас 
собственная мастерская).

Размещение рекламных вывесок в Вашем здании возможно! Поток клиентов с улицы - 
быстро окупит вывеску.

Возможны варианты:
- Вывеска - от 5500 рублей
- Объемные буквы от 85 рублей см
- Световые короба 9000 рублей
- И другие виды рекламных конструкций.

По вывескам много вариантов - от реально недорогих до серьезных.

Если принципиальный интерес у Вас есть - просто напишите - какого размера и 
какого типа вывеску Вам хотелось бы - я смогу рассчитать стоимость изготовления 
и монтаж. 

С уважением, Михаил.

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  wrote:
> Hi Rafael,
>
> On 15-03-16, 16:10, Dawei Chien wrote:
>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register registering
>> cooling devices with dynamic power coefficient.
>>
>> Signed-off-by: Dawei Chien 
>> Acked-by: Viresh Kumar 
>
> Can you please apply this patch from Dawei ?

I can, but I'm traveling this week, so that's rather going to happen next week.

Thanks,
Rafael

Re: [RESEND][PATCH 1/3] thermal: mediatek: Add cpu dynamic power cooling model.

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 7:38 AM, Viresh Kumar  wrote:
> Hi Rafael,
>
> On 15-03-16, 16:10, Dawei Chien wrote:
>> MT8173 cpufreq driver select of_cpufreq_power_cooling_register registering
>> cooling devices with dynamic power coefficient.
>>
>> Signed-off-by: Dawei Chien 
>> Acked-by: Viresh Kumar 
>
> Can you please apply this patch from Dawei ?

I can, but I'm traveling this week, so that's rather going to happen next week.

Thanks,
Rafael

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Yuyang Du

Hi Vincent,

On Tue, Apr 12, 2016 at 01:56:45PM +0200, Vincent Guittot wrote:
> Le Tuesday 12 Apr 2016 à 03:41:41 (+0800), Yuyang Du a écrit :
> > Hi Vincent,
> > 
> > On Mon, Apr 11, 2016 at 11:08:04AM +0200, Vincent Guittot wrote:
> > > > @@ -2704,11 +2694,14 @@ static __always_inline int
> > > >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > > >   unsigned long weight, int running, struct cfs_rq 
> > > > *cfs_rq)
> > > >  {
> > > > -   u64 delta, scaled_delta, periods;
> > > > -   u32 contrib;
> > > > -   unsigned int delta_w, scaled_delta_w, decayed = 0;
> > > > +   u64 delta;
> > > > +   u32 contrib, periods;
> > > > unsigned long scale_freq, scale_cpu;
> > > >
> > > > +   /*
> > > > +* now rolls down to a period boundary
> > > > +*/
> > > > +   now = now && (u64)(~0xF);
> > > > delta = now - sa->last_update_time;
> > > > /*
> > > >  * This should only happen when time goes backwards, which it
> > > > @@ -2720,89 +2713,56 @@ __update_load_avg(u64 now, int cpu, struct 
> > > > sched_avg *sa,
> > > > }
> > > >
> > > > /*
> > > > -* Use 1024ns as the unit of measurement since it's a reasonable
> > > > -* approximation of 1us and fast to compute.
> > > > +* Use 1024*1024ns as an approximation of 1ms period, pretty 
> > > > close.
> > > >  */
> > > > -   delta >>= 10;
> > > > -   if (!delta)
> > > > +   periods = delta >> 20;
> > > > +   if (!periods)
> > > > return 0;
> > > > sa->last_update_time = now;
> > > 
> > > The optimization looks quite interesting but I see one potential issue
> > > with migration as we will lose the part of the ongoing period that is
> > > now not saved anymore. This lost part can be quite significant for a
> > > short task that ping pongs between CPUs.
> > 
> > Yes, basically, it is we lose precision (~1ms scale in contrast with ~1us 
> > scale).
> 
> But with a HZ set to 1000 and a sched-slice in the same range, having a 
> precision
> of 1ms instead of 1us makes the precision of load tracking of short task quite
> random IMHO.
> 
> you can keep recording this partial period without using it in the load 
> tracking.
> Something like below keep precision without sacrifying the optimization.
 
The residue is accumulated and rolled over to next update every time. But its
state is runnable/not-runnable, or running/not-running?

> ---
>  kernel/sched/fair.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 68273e8..b234169 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -674,6 +674,12 @@ void init_entity_runnable_average(struct sched_entity 
> *se)
>   struct sched_avg *sa = >avg;
>  
>   sa->last_update_time = 0;
> + /*
> +  * sched_avg's period_contrib should be strictly less then 1024 * 1024, 
> so
> +  * we give it 1023 * 1024 to make sure it is almost a period (1024us), 
> and
> +  * will definitely be updated (after enqueue).
> +  */
> + sa->period_contrib = 1023*1024;
>   sa->load_avg = scale_load_down(se->load.weight);
>   sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
>   /*
> @@ -2698,10 +2704,6 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   u32 contrib, periods;
>   unsigned long scale_freq, scale_cpu;
>  
> - /*
> -  * now rolls down to a period boundary
> -  */
> - now = now && (u64)(~0xF);
>   delta = now - sa->last_update_time;
>   /*
>* This should only happen when time goes backwards, which it
> @@ -2712,6 +2714,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   return 0;
>   }
>  
> + /* Add how much left for the current period */
> + delta += sa->period_contrib;
> +
>   /*
>* Use 1024*1024ns as an approximation of 1ms period, pretty close.
>*/
> @@ -2720,6 +2725,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   return 0;
>   sa->last_update_time = now;
>  
> + /* Get how much left for the next period */
> + sa->period_contrib = delta & (u64)(0xF);
> +
>   scale_freq = arch_scale_freq_capacity(NULL, cpu);
>   scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
> 
> > But as I wrote, we may either lose a sub-1ms, or gain a sub-1ms, 
> > statistically,
> > they should even out, given the load/util updates are quite a large number 
> > of
> > samples, and we do want a lot of samples for the metrics, this is the point 
> > of
> > the entire average thing. Plus, as you also said, the incomplete current 
> > period
> > also plays a (somewhat) negative role here.
> > 
> > In addition, excluding the flat hierarchical util patch, we gain quite some
> > efficiency.

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Yuyang Du

Hi Vincent,

On Tue, Apr 12, 2016 at 01:56:45PM +0200, Vincent Guittot wrote:
> Le Tuesday 12 Apr 2016 à 03:41:41 (+0800), Yuyang Du a écrit :
> > Hi Vincent,
> > 
> > On Mon, Apr 11, 2016 at 11:08:04AM +0200, Vincent Guittot wrote:
> > > > @@ -2704,11 +2694,14 @@ static __always_inline int
> > > >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > > >   unsigned long weight, int running, struct cfs_rq 
> > > > *cfs_rq)
> > > >  {
> > > > -   u64 delta, scaled_delta, periods;
> > > > -   u32 contrib;
> > > > -   unsigned int delta_w, scaled_delta_w, decayed = 0;
> > > > +   u64 delta;
> > > > +   u32 contrib, periods;
> > > > unsigned long scale_freq, scale_cpu;
> > > >
> > > > +   /*
> > > > +* now rolls down to a period boundary
> > > > +*/
> > > > +   now = now && (u64)(~0xF);
> > > > delta = now - sa->last_update_time;
> > > > /*
> > > >  * This should only happen when time goes backwards, which it
> > > > @@ -2720,89 +2713,56 @@ __update_load_avg(u64 now, int cpu, struct 
> > > > sched_avg *sa,
> > > > }
> > > >
> > > > /*
> > > > -* Use 1024ns as the unit of measurement since it's a reasonable
> > > > -* approximation of 1us and fast to compute.
> > > > +* Use 1024*1024ns as an approximation of 1ms period, pretty 
> > > > close.
> > > >  */
> > > > -   delta >>= 10;
> > > > -   if (!delta)
> > > > +   periods = delta >> 20;
> > > > +   if (!periods)
> > > > return 0;
> > > > sa->last_update_time = now;
> > > 
> > > The optimization looks quite interesting but I see one potential issue
> > > with migration as we will lose the part of the ongoing period that is
> > > now not saved anymore. This lost part can be quite significant for a
> > > short task that ping pongs between CPUs.
> > 
> > Yes, basically, it is we lose precision (~1ms scale in contrast with ~1us 
> > scale).
> 
> But with a HZ set to 1000 and a sched-slice in the same range, having a 
> precision
> of 1ms instead of 1us makes the precision of load tracking of short task quite
> random IMHO.
> 
> you can keep recording this partial period without using it in the load 
> tracking.
> Something like below keep precision without sacrifying the optimization.
 
The residue is accumulated and rolled over to next update every time. But its
state is runnable/not-runnable, or running/not-running?

> ---
>  kernel/sched/fair.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 68273e8..b234169 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -674,6 +674,12 @@ void init_entity_runnable_average(struct sched_entity 
> *se)
>   struct sched_avg *sa = >avg;
>  
>   sa->last_update_time = 0;
> + /*
> +  * sched_avg's period_contrib should be strictly less then 1024 * 1024, 
> so
> +  * we give it 1023 * 1024 to make sure it is almost a period (1024us), 
> and
> +  * will definitely be updated (after enqueue).
> +  */
> + sa->period_contrib = 1023*1024;
>   sa->load_avg = scale_load_down(se->load.weight);
>   sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
>   /*
> @@ -2698,10 +2704,6 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   u32 contrib, periods;
>   unsigned long scale_freq, scale_cpu;
>  
> - /*
> -  * now rolls down to a period boundary
> -  */
> - now = now && (u64)(~0xF);
>   delta = now - sa->last_update_time;
>   /*
>* This should only happen when time goes backwards, which it
> @@ -2712,6 +2714,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   return 0;
>   }
>  
> + /* Add how much left for the current period */
> + delta += sa->period_contrib;
> +
>   /*
>* Use 1024*1024ns as an approximation of 1ms period, pretty close.
>*/
> @@ -2720,6 +2725,9 @@ __update_load_avg(u64 now, int cpu, struct sched_avg 
> *sa,
>   return 0;
>   sa->last_update_time = now;
>  
> + /* Get how much left for the next period */
> + sa->period_contrib = delta & (u64)(0xF);
> +
>   scale_freq = arch_scale_freq_capacity(NULL, cpu);
>   scale_cpu = arch_scale_cpu_capacity(NULL, cpu);
> 
> > But as I wrote, we may either lose a sub-1ms, or gain a sub-1ms, 
> > statistically,
> > they should even out, given the load/util updates are quite a large number 
> > of
> > samples, and we do want a lot of samples for the metrics, this is the point 
> > of
> > the entire average thing. Plus, as you also said, the incomplete current 
> > period
> > also plays a (somewhat) negative role here.
> > 
> > In addition, excluding the flat hierarchical util patch, we gain quite some
> > efficiency.

Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg()

2016-04-12 Thread Rafael J. Wysocki

On Wed, Apr 13, 2016 at 2:08 AM, Steve Muckle  wrote:
> On Tue, Apr 12, 2016 at 04:29:06PM +0200, Rafael J. Wysocki wrote:
>> This is rather fundamental.
>>
>> For example, if you look at cpufreq_update_util(), it does this:
>>
>> data = rcu_dereference_sched(*this_cpu_ptr(_update_util_data));
>>
>> meaning that it will run the current CPU's utilization update
>> callback.  Of course, that won't work cross-CPU, because in principle
>> different CPUs may use different governors and therefore different
>> util update callbacks.
>
> Will something like the attached (unfinished patches) work? It seems
> to for me, but I haven't tested it much beyond confirming the hook is
> working on remote wakeups.

No, they are not sufficient.

First of all, you need to take all of the governors into account and
they all make assumptions about updates being run on the CPU being
updated.

That should be easy to take into account for ondemand/conservative,
but intel_pstate is a different story.

> I'm relying on the previous comment that it's up to cpufreq drivers to
> run stuff on the target policy's CPUs if the driver needs that.

That's not the case for the fast frequency switching though, which has
to happen on the CPU running the code.

> There's still some more work, fixing up some more smp_processor_id()
> usage in schedutil, but it should be easy (trace, slow path irq_work
> target).
>
>> If you want to do remote updates, I guess that will require an
>> irq_work to run the update on the target CPU, but then you'll probably
>> want to neglect the rate limit on it as well, so it looks like a
>> "need_update" flag in struct update_util_data will be useful for that.
>
> Why is it required to run the update on the target CPU?

The fast switching and intel_pstate are the main reason.

They both have to write to registers of the target CPU and the code to
do that needs to run on that CPU.

Thanks,
Rafael

Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg()

2016-04-12 Thread Rafael J. Wysocki

On Wed, Apr 13, 2016 at 2:08 AM, Steve Muckle  wrote:
> On Tue, Apr 12, 2016 at 04:29:06PM +0200, Rafael J. Wysocki wrote:
>> This is rather fundamental.
>>
>> For example, if you look at cpufreq_update_util(), it does this:
>>
>> data = rcu_dereference_sched(*this_cpu_ptr(_update_util_data));
>>
>> meaning that it will run the current CPU's utilization update
>> callback.  Of course, that won't work cross-CPU, because in principle
>> different CPUs may use different governors and therefore different
>> util update callbacks.
>
> Will something like the attached (unfinished patches) work? It seems
> to for me, but I haven't tested it much beyond confirming the hook is
> working on remote wakeups.

No, they are not sufficient.

First of all, you need to take all of the governors into account and
they all make assumptions about updates being run on the CPU being
updated.

That should be easy to take into account for ondemand/conservative,
but intel_pstate is a different story.

> I'm relying on the previous comment that it's up to cpufreq drivers to
> run stuff on the target policy's CPUs if the driver needs that.

That's not the case for the fast frequency switching though, which has
to happen on the CPU running the code.

> There's still some more work, fixing up some more smp_processor_id()
> usage in schedutil, but it should be easy (trace, slow path irq_work
> target).
>
>> If you want to do remote updates, I guess that will require an
>> irq_work to run the update on the target CPU, but then you'll probably
>> want to neglect the rate limit on it as well, so it looks like a
>> "need_update" flag in struct update_util_data will be useful for that.
>
> Why is it required to run the update on the target CPU?

The fast switching and intel_pstate are the main reason.

They both have to write to registers of the target CPU and the code to
do that needs to run on that CPU.

Thanks,
Rafael

Re: Is there any race between flush_to_ldisc() and release_one_tty()?

2016-04-12 Thread Peter Hurley

Hi Prasad,

Thanks for the report.

On 04/12/2016 08:22 AM, Sodagudi Prasad wrote:
> 
> Hi All,
> 
> It looks like there is race between flush_to_ldisc() and release_one_tty().

Not necessarily.

Driver could have destroyed the port prematurely. Or the driver could have
rescheduled the input kworker after it was cancelled in release_tty().

What driver is this?

> Following crash is observed even after including below change.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/tty_buffer.c?id=7098296a362a96051fa120abf48f0095818b99cd
> https://lkml.org/lkml/2015/9/1/491
> 
> 
> [386532.450351] Unable to handle kernel paging request at virtual address 
> 6b6b6b6b6b6b6b93
> [386532.465217] pgd = ffc05bea5000
> [386532.467677] [6b6b6b6b6b6b6b93] *pgd=, 
> *pud=
> [386532.474715] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [386532.480350] Modules linked in: wlan(O) [last unloaded: wlan]
> [386532.486085] CPU: 5 PID: 31970 Comm: kworker/5:1 Tainted: GW  O   
> 3.18.24-ga9bbc02-00076-g1434803 #1
> [386532.495885] Hardware name: Qualcomm Technologies, Inc. MSM8953 MTP (DT)
> [386532.502581] Workqueue: events flush_to_ldisc
> [386532.506909] task: ffc06162 ti: ffc011efc000 task.ti: 
> ffc011efc000
> [386532.514465] PC is at ldsem_down_read_trylock+0x0/0x48
> [386532.519583] LR is at tty_ldisc_ref+0x24/0x4c
> 
> 
> 
> [386533.028262] Process kworker/5:1 (pid: 31970, stack limit = 
> 0xffc011efc058)
> [386533.035553] Call trace:
> [386533.038080] [] ldsem_down_read_trylock+0x0/0x48
> [386533.044236] [] flush_to_ldisc+0x28/0x124
> [386533.049794] [] process_one_work+0x238/0x3f0
> [386533.055608] [] worker_thread+0x2f8/0x418
> [386533.061163] [] kthread+0xec/0xf8

Why is this trace report elided?

Does this happen on vanilla 3.18.24 kernel? What about a more recent kernel?

> 1) It is not clear how READ_ONCE would fix the race between flush_to_ldisc() 
> and release_one_tty() discussed in https://lkml.org/lkml/2015/9/1/491. could 
> you please provide more information?

It doesn't.

READ_ONCE() only guarantees the compiler won't reload tty from port->itty after
the check for NULL; that in turn guarantees that the kworker hasn't been 
cancelled
yet (since it's now running) and release_tty() can't advance until this kworker
completes.

IOW, the kworker cancel in release_tty() is what guarantees flush_to_ldisc()
is not concurrent with release_one_tty().

But this doesn't factor in at all in the observed crash.
Although the information provided is quite limited(?!), the tty address itself
is bogus; not that this used to point to a valid-but-now-free tty.

What's most likely happened is the tty port has been freed while its
buffer work was running, which is almost certainly a driver bug.

> 2) Is there any chance that, other core could free tty memory between 442 and 
> 445 lines?

Sure, but I don't think that's what's happened here.
As I wrote above, more likely the port has been freed, so the value
retrieved for port->itty was bogus.

FWIW, the ipwireless tty driver will happily free the tty while it's in use.

And the serial core will let you unload the uart driver and free the tty
ports while the tty is open and in use, as well.

> 434 static void flush_to_ldisc(struct work_struct *work)
> 435 {
> ...
> ...
> ...
> 441 tty = READ_ONCE(port->itty);
> 442 if (tty == NULL)
> 443 return;
> 444
> 445 disc = tty_ldisc_ref(tty);
> 446 if (disc == NULL)
> 447 return;

Re: Is there any race between flush_to_ldisc() and release_one_tty()?

2016-04-12 Thread Peter Hurley

Hi Prasad,

Thanks for the report.

On 04/12/2016 08:22 AM, Sodagudi Prasad wrote:
> 
> Hi All,
> 
> It looks like there is race between flush_to_ldisc() and release_one_tty().

Not necessarily.

Driver could have destroyed the port prematurely. Or the driver could have
rescheduled the input kworker after it was cancelled in release_tty().

What driver is this?

> Following crash is observed even after including below change.
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/tty/tty_buffer.c?id=7098296a362a96051fa120abf48f0095818b99cd
> https://lkml.org/lkml/2015/9/1/491
> 
> 
> [386532.450351] Unable to handle kernel paging request at virtual address 
> 6b6b6b6b6b6b6b93
> [386532.465217] pgd = ffc05bea5000
> [386532.467677] [6b6b6b6b6b6b6b93] *pgd=, 
> *pud=
> [386532.474715] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [386532.480350] Modules linked in: wlan(O) [last unloaded: wlan]
> [386532.486085] CPU: 5 PID: 31970 Comm: kworker/5:1 Tainted: GW  O   
> 3.18.24-ga9bbc02-00076-g1434803 #1
> [386532.495885] Hardware name: Qualcomm Technologies, Inc. MSM8953 MTP (DT)
> [386532.502581] Workqueue: events flush_to_ldisc
> [386532.506909] task: ffc06162 ti: ffc011efc000 task.ti: 
> ffc011efc000
> [386532.514465] PC is at ldsem_down_read_trylock+0x0/0x48
> [386532.519583] LR is at tty_ldisc_ref+0x24/0x4c
> 
> 
> 
> [386533.028262] Process kworker/5:1 (pid: 31970, stack limit = 
> 0xffc011efc058)
> [386533.035553] Call trace:
> [386533.038080] [] ldsem_down_read_trylock+0x0/0x48
> [386533.044236] [] flush_to_ldisc+0x28/0x124
> [386533.049794] [] process_one_work+0x238/0x3f0
> [386533.055608] [] worker_thread+0x2f8/0x418
> [386533.061163] [] kthread+0xec/0xf8

Why is this trace report elided?

Does this happen on vanilla 3.18.24 kernel? What about a more recent kernel?

> 1) It is not clear how READ_ONCE would fix the race between flush_to_ldisc() 
> and release_one_tty() discussed in https://lkml.org/lkml/2015/9/1/491. could 
> you please provide more information?

It doesn't.

READ_ONCE() only guarantees the compiler won't reload tty from port->itty after
the check for NULL; that in turn guarantees that the kworker hasn't been 
cancelled
yet (since it's now running) and release_tty() can't advance until this kworker
completes.

IOW, the kworker cancel in release_tty() is what guarantees flush_to_ldisc()
is not concurrent with release_one_tty().

But this doesn't factor in at all in the observed crash.
Although the information provided is quite limited(?!), the tty address itself
is bogus; not that this used to point to a valid-but-now-free tty.

What's most likely happened is the tty port has been freed while its
buffer work was running, which is almost certainly a driver bug.

> 2) Is there any chance that, other core could free tty memory between 442 and 
> 445 lines?

Sure, but I don't think that's what's happened here.
As I wrote above, more likely the port has been freed, so the value
retrieved for port->itty was bogus.

FWIW, the ipwireless tty driver will happily free the tty while it's in use.

And the serial core will let you unload the uart driver and free the tty
ports while the tty is open and in use, as well.

> 434 static void flush_to_ldisc(struct work_struct *work)
> 435 {
> ...
> ...
> ...
> 441 tty = READ_ONCE(port->itty);
> 442 if (tty == NULL)
> 443 return;
> 444
> 445 disc = tty_ldisc_ref(tty);
> 446 if (disc == NULL)
> 447 return;

[PATCH v2] arm64: dts: Add nodes for pdma0 and pdam1 for exynos7

2016-04-12 Thread Alim Akhtar

This patch adds device tree nodes for pdma0 and pdma1 controllers
found on exynos7 SoCs.

Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 93108f1..a1a3dba 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -95,6 +95,35 @@
<0x11006000 0x2000>;
};
 
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   pdma0: pdma@10E1 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x10E1 0x1000>;
+   interrupts = <0 225 0>;
+   clocks = <_fsys0 ACLK_PDMA0>;
+   clock-names = "apb_pclk";
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   };
+
+   pdma1: pdma@10EB {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x10EB 0x1000>;
+   interrupts = <0 226 0>;
+   clocks = <_fsys0 ACLK_PDMA1>;
+   clock-names = "apb_pclk";
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   };
+   };
+
clock_topc: clock-controller@1057 {
compatible = "samsung,exynos7-clock-topc";
reg = <0x1057 0x1>;
-- 
1.7.10.4

[PATCH v2] arm64: dts: Add nodes for pdma0 and pdam1 for exynos7

2016-04-12 Thread Alim Akhtar

This patch adds device tree nodes for pdma0 and pdma1 controllers
found on exynos7 SoCs.

Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 93108f1..a1a3dba 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -95,6 +95,35 @@
<0x11006000 0x2000>;
};
 
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   pdma0: pdma@10E1 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x10E1 0x1000>;
+   interrupts = <0 225 0>;
+   clocks = <_fsys0 ACLK_PDMA0>;
+   clock-names = "apb_pclk";
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   };
+
+   pdma1: pdma@10EB {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0x10EB 0x1000>;
+   interrupts = <0 226 0>;
+   clocks = <_fsys0 ACLK_PDMA1>;
+   clock-names = "apb_pclk";
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   };
+   };
+
clock_topc: clock-controller@1057 {
compatible = "samsung,exynos7-clock-topc";
reg = <0x1057 0x1>;
-- 
1.7.10.4

Re: [PATCH] arm64: dts: Add nodes for pdma0 and pdam1 for exynos7

2016-04-12 Thread Alim Akhtar


Hi Krzysztof,

On 04/12/2016 07:35 PM, Krzysztof Kozlowski wrote:

On 04/12/2016 02:49 PM, Alim Akhtar wrote:

This patch adds device tree nodes for pdma0 and pdma1 controllers
found on exynos7 SoCs.

Signed-off-by: Alim Akhtar 
---
  arch/arm64/boot/dts/exynos/exynos7.dtsi |   29 +
  1 file changed, 29 insertions(+)



I would prefer avoid adding all new stuff at the end because it is
conflict-prone. Alphabetical order or by address... but none of these
are used currently. How about putting it after 'gic' node?


hmmok will send v2 with suggested changes.
Looks like other platforms also put it below 'gic'.


Anyway the code looks fine:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] arm64: dts: Add nodes for pdma0 and pdam1 for exynos7

2016-04-12 Thread Alim Akhtar


Hi Krzysztof,

On 04/12/2016 07:35 PM, Krzysztof Kozlowski wrote:

On 04/12/2016 02:49 PM, Alim Akhtar wrote:

This patch adds device tree nodes for pdma0 and pdma1 controllers
found on exynos7 SoCs.

Signed-off-by: Alim Akhtar 
---
  arch/arm64/boot/dts/exynos/exynos7.dtsi |   29 +
  1 file changed, 29 insertions(+)



I would prefer avoid adding all new stuff at the end because it is
conflict-prone. Alphabetical order or by address... but none of these
are used currently. How about putting it after 'gic' node?


hmmok will send v2 with suggested changes.
Looks like other platforms also put it below 'gic'.


Anyway the code looks fine:
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH v3] device property: don't bother the drivers with struct property_set

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 9:24 AM, Lee Jones  wrote:
> On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>
>> On Mon, Apr 11, 2016 at 6:20 PM, Lee Jones  wrote:
>> > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>> >
>> >> On Mon, Apr 11, 2016 at 4:05 PM, Lee Jones  wrote:
>> >> > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>> >> >
>> >> >> On Mon, Apr 11, 2016 at 11:52 AM, Heikki Krogerus
>> >> >>  wrote:
>> >> >> > On Mon, Apr 11, 2016 at 09:20:27AM +0100, Lee Jones wrote:
>> >> >> >> On Tue, 29 Mar 2016, Heikki Krogerus wrote:
>> >> >> >>
>> >> >> >> > Since device_add_property_set() now always takes a copy of
>> >> >> >> > the property_set, and also since the fwnode type is always
>> >> >> >> > hard coded to be FWNODE_PDATA, there is no need for the
>> >> >> >> > drivers to deliver the entire struct property_set. The
>> >> >> >> > function can just create the instance of it on its own and
>> >> >> >> > bind the properties from the drivers to it on the spot.
>> >> >> >> >
>> >> >> >> > This renames device_add_property_set() to
>> >> >> >> > device_add_properties(). The function now takes struct
>> >> >> >> > property_entry as its parameter instead of struct
>> >> >> >> > property_set.
>> >> >> >> >
>> >> >> >> > Reviewed-by: Andy Shevchenko 
>> >> >> >> > Reviewed-by: Mika Westerberg 
>> >> >> >> > Acked-by: Thierry Reding 
>> >> >> >> > Acked-by: Lee Jones 
>> >> >> >> > Signed-off-by: Heikki Krogerus 
>> >> >> >> > ---
>> >> >> >> >  arch/arm/mach-pxa/raumfeld.c  | 12 
>> >> >> >
>> >> >> > Daniel, I think we just need your ACK for this one.
>> >> >> >
>> >> >> > Otherwise I think we are covered.
>> >> >> >
>> >> >> >> >  arch/arm/mach-tegra/board-paz00.c |  6 +-
>> >> >> >> >  drivers/base/platform.c   | 19 ++-
>> >> >> >> >  drivers/base/property.c   | 34 
>> >> >> >> > +-
>> >> >> >> >  drivers/mfd/intel-lpss-acpi.c | 12 ++--
>> >> >> >> >  drivers/mfd/intel-lpss-pci.c  | 20 
>> >> >> >> >  drivers/mfd/intel-lpss.c  |  2 +-
>> >> >> >> >  drivers/mfd/intel-lpss.h  |  4 ++--
>> >> >> >> >  drivers/mfd/mfd-core.c|  4 ++--
>> >> >> >> >  include/linux/mfd/core.h  |  4 ++--
>> >> >> >> >  include/linux/platform_device.h   |  6 +++---
>> >> >> >> >  include/linux/property.h  | 15 +++
>> >> >> >> >  12 files changed, 55 insertions(+), 83 deletions(-)
>> >> >> >>
>> >> >> >> What's happening with this patch?  I believe we're still missing
>> >> >> >> Acks.  Once they are collected someone needs to create an immutable
>> >> >> >> branch and send out a pull-request.
>> >> >> >
>> >> >> > Rafael, have you had time to take a look at this?
>> >> >>
>> >> >> Yes, it's in my bleeding-edge branch now.  I'm planning to move it to
>> >> >> linux-next this week
>> >> >
>> >> > Please ensure you send out the relevant pull-requests.  Linus doesn't
>> >> > look his best when he's angry.
>> >>
>> >> I guess you mean I should expose by device-properties branch and
>> >> notify the relevant people about that, right?
>> >
>> > Exactly.  And the easiest way to do that is by sending out a
>> > pull-request.
>>
>> I hoping that sending a message with the relevant information in a
>> reply to this one will be sufficient.
>
> Because of the nature of MFD, I end up doing this kind of thing a lot.
>
> Here's what I normally do.  Normally in reply to the cover-letter (0/x):
>   https://lkml.org/lkml/2015/8/12/138

OK, makes sense.

Thanks,
Rafael

Re: [PATCH v3] device property: don't bother the drivers with struct property_set

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 9:24 AM, Lee Jones  wrote:
> On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>
>> On Mon, Apr 11, 2016 at 6:20 PM, Lee Jones  wrote:
>> > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>> >
>> >> On Mon, Apr 11, 2016 at 4:05 PM, Lee Jones  wrote:
>> >> > On Mon, 11 Apr 2016, Rafael J. Wysocki wrote:
>> >> >
>> >> >> On Mon, Apr 11, 2016 at 11:52 AM, Heikki Krogerus
>> >> >>  wrote:
>> >> >> > On Mon, Apr 11, 2016 at 09:20:27AM +0100, Lee Jones wrote:
>> >> >> >> On Tue, 29 Mar 2016, Heikki Krogerus wrote:
>> >> >> >>
>> >> >> >> > Since device_add_property_set() now always takes a copy of
>> >> >> >> > the property_set, and also since the fwnode type is always
>> >> >> >> > hard coded to be FWNODE_PDATA, there is no need for the
>> >> >> >> > drivers to deliver the entire struct property_set. The
>> >> >> >> > function can just create the instance of it on its own and
>> >> >> >> > bind the properties from the drivers to it on the spot.
>> >> >> >> >
>> >> >> >> > This renames device_add_property_set() to
>> >> >> >> > device_add_properties(). The function now takes struct
>> >> >> >> > property_entry as its parameter instead of struct
>> >> >> >> > property_set.
>> >> >> >> >
>> >> >> >> > Reviewed-by: Andy Shevchenko 
>> >> >> >> > Reviewed-by: Mika Westerberg 
>> >> >> >> > Acked-by: Thierry Reding 
>> >> >> >> > Acked-by: Lee Jones 
>> >> >> >> > Signed-off-by: Heikki Krogerus 
>> >> >> >> > ---
>> >> >> >> >  arch/arm/mach-pxa/raumfeld.c  | 12 
>> >> >> >
>> >> >> > Daniel, I think we just need your ACK for this one.
>> >> >> >
>> >> >> > Otherwise I think we are covered.
>> >> >> >
>> >> >> >> >  arch/arm/mach-tegra/board-paz00.c |  6 +-
>> >> >> >> >  drivers/base/platform.c   | 19 ++-
>> >> >> >> >  drivers/base/property.c   | 34 
>> >> >> >> > +-
>> >> >> >> >  drivers/mfd/intel-lpss-acpi.c | 12 ++--
>> >> >> >> >  drivers/mfd/intel-lpss-pci.c  | 20 
>> >> >> >> >  drivers/mfd/intel-lpss.c  |  2 +-
>> >> >> >> >  drivers/mfd/intel-lpss.h  |  4 ++--
>> >> >> >> >  drivers/mfd/mfd-core.c|  4 ++--
>> >> >> >> >  include/linux/mfd/core.h  |  4 ++--
>> >> >> >> >  include/linux/platform_device.h   |  6 +++---
>> >> >> >> >  include/linux/property.h  | 15 +++
>> >> >> >> >  12 files changed, 55 insertions(+), 83 deletions(-)
>> >> >> >>
>> >> >> >> What's happening with this patch?  I believe we're still missing
>> >> >> >> Acks.  Once they are collected someone needs to create an immutable
>> >> >> >> branch and send out a pull-request.
>> >> >> >
>> >> >> > Rafael, have you had time to take a look at this?
>> >> >>
>> >> >> Yes, it's in my bleeding-edge branch now.  I'm planning to move it to
>> >> >> linux-next this week
>> >> >
>> >> > Please ensure you send out the relevant pull-requests.  Linus doesn't
>> >> > look his best when he's angry.
>> >>
>> >> I guess you mean I should expose by device-properties branch and
>> >> notify the relevant people about that, right?
>> >
>> > Exactly.  And the easiest way to do that is by sending out a
>> > pull-request.
>>
>> I hoping that sending a message with the relevant information in a
>> reply to this one will be sufficient.
>
> Because of the nature of MFD, I end up doing this kind of thing a lot.
>
> Here's what I normally do.  Normally in reply to the cover-letter (0/x):
>   https://lkml.org/lkml/2015/8/12/138

OK, makes sense.

Thanks,
Rafael

Re: [PATCH 1/3] ACPI / tables: Move table override mechanisms to tables.c

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 1:27 AM, Zheng, Lv  wrote:
> Hi,
>
>> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
>> Rafael J. Wysocki
>> Sent: Monday, April 11, 2016 9:31 PM
>> Subject: Re: [PATCH 1/3] ACPI / tables: Move table override mechanisms to
>> tables.c
>>
>> On Mon, Apr 11, 2016 at 4:16 AM, Zheng, Lv  wrote:
>> > Hi, Rafael
>>
>> Hi,
>>
>> >> From: Zheng, Lv
>> >> Subject: [PATCH 1/3] ACPI / tables: Move table override mechanisms to
>> >> tables.c
>> >>
>> >> This patch moves acpi_os_table_override() and
>> >> acpi_os_physical_table_override() to tables.c.
>> >>
>>
>> [cut]
>>
>> >>  #ifdef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
>> >> -void acpi_initrd_override(void *data, size_t size);
>> >> +void early_acpi_table_init(void *data, size_t size);
>> >>  #else
>> >> -static inline void acpi_initrd_override(void *data, size_t size)
>> >> +static inline void early_acpi_table_init(void *data, size_t size)
>> >>  {
>> >>  }
>> >>  #endif
>> > [Lv Zheng]
>> > This block was wrong.
>> > early_acpi_table_init() is no longer dependent on
>> CONFIG_ACPI_INITRD_TABLE_OVERRIDE but dependent on CONFIG_ACPI.
>>
>> I see.
>>
>> > Updated v2 patches are sent to the mailing list.
>>
>> Is this the only difference between v1 and v2?
>
> [Lv Zheng]
> One of the follow-up patches (PATCH 3) in this series is updated accordingly.

OK, thanks.

It generally is good to add that type of information to the patches in
the new version (in an additional section below the sign-off tag).

Thanks,
Rafael

Re: [PATCH 1/3] ACPI / tables: Move table override mechanisms to tables.c

2016-04-12 Thread Rafael J. Wysocki

On Tue, Apr 12, 2016 at 1:27 AM, Zheng, Lv  wrote:
> Hi,
>
>> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of
>> Rafael J. Wysocki
>> Sent: Monday, April 11, 2016 9:31 PM
>> Subject: Re: [PATCH 1/3] ACPI / tables: Move table override mechanisms to
>> tables.c
>>
>> On Mon, Apr 11, 2016 at 4:16 AM, Zheng, Lv  wrote:
>> > Hi, Rafael
>>
>> Hi,
>>
>> >> From: Zheng, Lv
>> >> Subject: [PATCH 1/3] ACPI / tables: Move table override mechanisms to
>> >> tables.c
>> >>
>> >> This patch moves acpi_os_table_override() and
>> >> acpi_os_physical_table_override() to tables.c.
>> >>
>>
>> [cut]
>>
>> >>  #ifdef CONFIG_ACPI_INITRD_TABLE_OVERRIDE
>> >> -void acpi_initrd_override(void *data, size_t size);
>> >> +void early_acpi_table_init(void *data, size_t size);
>> >>  #else
>> >> -static inline void acpi_initrd_override(void *data, size_t size)
>> >> +static inline void early_acpi_table_init(void *data, size_t size)
>> >>  {
>> >>  }
>> >>  #endif
>> > [Lv Zheng]
>> > This block was wrong.
>> > early_acpi_table_init() is no longer dependent on
>> CONFIG_ACPI_INITRD_TABLE_OVERRIDE but dependent on CONFIG_ACPI.
>>
>> I see.
>>
>> > Updated v2 patches are sent to the mailing list.
>>
>> Is this the only difference between v1 and v2?
>
> [Lv Zheng]
> One of the follow-up patches (PATCH 3) in this series is updated accordingly.

OK, thanks.

It generally is good to add that type of information to the patches in
the new version (in an additional section below the sign-off tag).

Thanks,
Rafael

Re: [PATCH V2 2/2] scripts: dtc: fix memory leak after realloc

2016-04-12 Thread David Gibson

On Tue, Apr 12, 2016 at 04:11:17PM -0500, Rob Herring wrote:
> On Tue, Apr 12, 2016 at 3:55 PM, Maxim Zhukov
>  wrote:
> > This commit fixed memory leak after errors realloc.
> >
> > Signed-off-by: Maxim Zhukov 
> > ---
> >  scripts/dtc/fdtput.c | 10 +++---
> 
> Again, your patch is against the kernel copy of dtc. It needs to be
> against upstream dtc and then I can update the kernel copy once this
> lands.

Right.  TBH, I'm not particularly concerned about the leak anyway.
The memory will be freed when fdtput exits moments later, so it's
really not a big deal.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH V2 2/2] scripts: dtc: fix memory leak after realloc

2016-04-12 Thread David Gibson

On Tue, Apr 12, 2016 at 04:11:17PM -0500, Rob Herring wrote:
> On Tue, Apr 12, 2016 at 3:55 PM, Maxim Zhukov
>  wrote:
> > This commit fixed memory leak after errors realloc.
> >
> > Signed-off-by: Maxim Zhukov 
> > ---
> >  scripts/dtc/fdtput.c | 10 +++---
> 
> Again, your patch is against the kernel copy of dtc. It needs to be
> against upstream dtc and then I can update the kernel copy once this
> lands.

Right.  TBH, I'm not particularly concerned about the leak anyway.
The memory will be freed when fdtput exits moments later, so it's
really not a big deal.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Joe Perches

On Wed, 2016-04-13 at 04:14 +0800, Yuyang Du wrote:
> On Tue, Apr 12, 2016 at 01:02:58PM +0100, Dietmar Eggemann wrote:
> > On 10/04/16 23:36, Yuyang Du wrote:
> > [...]
> > > @@ -2704,11 +2694,14 @@ static __always_inline int
> > >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > >     unsigned long weight, int running, struct cfs_rq *cfs_rq)
> > >  {
> > > - u64 delta, scaled_delta, periods;
> > > - u32 contrib;
> > > - unsigned int delta_w, scaled_delta_w, decayed = 0;
> > > + u64 delta;
> > > + u32 contrib, periods;
> > >   unsigned long scale_freq, scale_cpu;
> > >  
> > > + /*
> > > +  * now rolls down to a period boundary
> > > +  */
> > > + now = now && (u64)(~0xF);
> > This forces now to be 1.
> > 
> > s/&&/&
> Duh, :)

You could also avoid the cast:

now &= 0xull;

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Joe Perches

On Wed, 2016-04-13 at 04:14 +0800, Yuyang Du wrote:
> On Tue, Apr 12, 2016 at 01:02:58PM +0100, Dietmar Eggemann wrote:
> > On 10/04/16 23:36, Yuyang Du wrote:
> > [...]
> > > @@ -2704,11 +2694,14 @@ static __always_inline int
> > >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> > >     unsigned long weight, int running, struct cfs_rq *cfs_rq)
> > >  {
> > > - u64 delta, scaled_delta, periods;
> > > - u32 contrib;
> > > - unsigned int delta_w, scaled_delta_w, decayed = 0;
> > > + u64 delta;
> > > + u32 contrib, periods;
> > >   unsigned long scale_freq, scale_cpu;
> > >  
> > > + /*
> > > +  * now rolls down to a period boundary
> > > +  */
> > > + now = now && (u64)(~0xF);
> > This forces now to be 1.
> > 
> > s/&&/&
> Duh, :)

You could also avoid the cast:

now &= 0xull;

[PATCH] i2c: cpm: Fix build break due to incompatible pointer types

2016-04-12 Thread Michael Ellerman

Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:

  drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
  'dma_alloc_coherent' from incompatible pointer type

Fix the build break by converting txdma & rxdma to dma_addr_t.

Signed-off-by: Michael Ellerman 
---
 drivers/i2c/busses/i2c-cpm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

*** Build tested only.

diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 714bdc837769..b167ab25310a 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -116,8 +116,8 @@ struct cpm_i2c {
cbd_t __iomem *rbase;
u_char *txbuf[CPM_MAXBD];
u_char *rxbuf[CPM_MAXBD];
-   u32 txdma[CPM_MAXBD];
-   u32 rxdma[CPM_MAXBD];
+   dma_addr_t txdma[CPM_MAXBD];
+   dma_addr_t rxdma[CPM_MAXBD];
 };
 
 static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
-- 
2.5.0

[PATCH] i2c: cpm: Fix build break due to incompatible pointer types

2016-04-12 Thread Michael Ellerman

Since commit ea8daa7b9784 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:

  drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
  'dma_alloc_coherent' from incompatible pointer type

Fix the build break by converting txdma & rxdma to dma_addr_t.

Signed-off-by: Michael Ellerman 
---
 drivers/i2c/busses/i2c-cpm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

*** Build tested only.

diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 714bdc837769..b167ab25310a 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -116,8 +116,8 @@ struct cpm_i2c {
cbd_t __iomem *rbase;
u_char *txbuf[CPM_MAXBD];
u_char *rxbuf[CPM_MAXBD];
-   u32 txdma[CPM_MAXBD];
-   u32 rxdma[CPM_MAXBD];
+   dma_addr_t txdma[CPM_MAXBD];
+   dma_addr_t rxdma[CPM_MAXBD];
 };
 
 static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
-- 
2.5.0

Re: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control

2016-04-12 Thread Michel Dänzer

On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> A regression was bisected to this commit:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=115321
> 
> Why not just provide stable with the bugfix as well?

What bugfix are you referring to? I'm not aware of any fix for this
regression.


>> So it's probably better to hold off on backporting this commit (and
>> possibly the corresponding amdgpu commit as well).
> 
> What specific commit are you referring to here?

bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1 ("drm/amdgpu: disable runtime
pm on PX laptops without dGPU power control")


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

Re: [PATCH 4.4 159/210] drm/radeon: disable runtime pm on PX laptops without dGPU power control

2016-04-12 Thread Michel Dänzer

On 12.04.2016 23:16, Greg Kroah-Hartman wrote:
> On Mon, Apr 11, 2016 at 11:26:00AM +0900, Michel Dänzer wrote:
>> On 11.04.2016 03:36, Greg Kroah-Hartman wrote:
>>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> A regression was bisected to this commit:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=115321
> 
> Why not just provide stable with the bugfix as well?

What bugfix are you referring to? I'm not aware of any fix for this
regression.


>> So it's probably better to hold off on backporting this commit (and
>> possibly the corresponding amdgpu commit as well).
> 
> What specific commit are you referring to here?

bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1 ("drm/amdgpu: disable runtime
pm on PX laptops without dGPU power control")


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

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Yuyang Du

On Tue, Apr 12, 2016 at 01:02:58PM +0100, Dietmar Eggemann wrote:
> On 10/04/16 23:36, Yuyang Du wrote:
> 
> [...]
> 
> > @@ -2704,11 +2694,14 @@ static __always_inline int
> >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> >   unsigned long weight, int running, struct cfs_rq *cfs_rq)
> >  {
> > -   u64 delta, scaled_delta, periods;
> > -   u32 contrib;
> > -   unsigned int delta_w, scaled_delta_w, decayed = 0;
> > +   u64 delta;
> > +   u32 contrib, periods;
> > unsigned long scale_freq, scale_cpu;
> >  
> > +   /*
> > +* now rolls down to a period boundary
> > +*/
> > +   now = now && (u64)(~0xF);
> 
> This forces now to be 1.
> 
> s/&&/&

Duh, :)

Thanks.

Re: [PATCH 2/4] sched/fair: Drop out incomplete current period when sched averages accrue

2016-04-12 Thread Yuyang Du

On Tue, Apr 12, 2016 at 01:02:58PM +0100, Dietmar Eggemann wrote:
> On 10/04/16 23:36, Yuyang Du wrote:
> 
> [...]
> 
> > @@ -2704,11 +2694,14 @@ static __always_inline int
> >  __update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> >   unsigned long weight, int running, struct cfs_rq *cfs_rq)
> >  {
> > -   u64 delta, scaled_delta, periods;
> > -   u32 contrib;
> > -   unsigned int delta_w, scaled_delta_w, decayed = 0;
> > +   u64 delta;
> > +   u32 contrib, periods;
> > unsigned long scale_freq, scale_cpu;
> >  
> > +   /*
> > +* now rolls down to a period boundary
> > +*/
> > +   now = now && (u64)(~0xF);
> 
> This forces now to be 1.
> 
> s/&&/&

Duh, :)

Thanks.

[PATCH 0/2] checkpatch: Document --fix capabilities a bit more

2016-04-12 Thread Joe Perches

The --fix option isn't well known so try to make it a bit more obvious.

Joe Perches (2):
  checkpatch: Advertise the --fix and --fix-inplace options more
  checkpatch: Add --list-types to show message types to show or ignore

 scripts/checkpatch.pl | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

-- 
2.8.0.rc4.16.g56331f8

[PATCH 0/2] checkpatch: Document --fix capabilities a bit more

2016-04-12 Thread Joe Perches

The --fix option isn't well known so try to make it a bit more obvious.

Joe Perches (2):
  checkpatch: Advertise the --fix and --fix-inplace options more
  checkpatch: Add --list-types to show message types to show or ignore

 scripts/checkpatch.pl | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

-- 
2.8.0.rc4.16.g56331f8

[PATCH 1/2] checkpatch: Advertise the --fix and --fix-inplace options more

2016-04-12 Thread Joe Perches

The --fix option is relatively unknown and underutilized.

Add some text to show that it's available when style defects are found.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3d9c34..c87913f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5940,6 +5940,14 @@ sub process {
}
 
if ($quiet == 0) {
+   # If there were any defects found and not already fixing them
+   if (!$clean and !$fix) {
+   print << "EOM"
+
+NOTE: For some of the reported defects, checkpatch may be able to
+  mechanically convert to the typical style using --fix or --fix-inplace.
+EOM
+   }
# If there were whitespace errors which cleanpatch can fix
# then suggest that.
if ($rpt_cleaners) {
-- 
2.8.0.rc4.16.g56331f8

[PATCH 2/2] checkpatch: Add --list-types to show message types to show or ignore

2016-04-12 Thread Joe Perches

The message types are not currently knowable without reading the code.
Add a mechanism to see what they are.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c87913f..abcafdb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -33,6 +33,7 @@ my $summary = 1;
 my $mailback = 0;
 my $summary_file = 0;
 my $show_types = 0;
+my $list_types = 0;
 my $fix = 0;
 my $fix_inplace = 0;
 my $root;
@@ -70,11 +71,12 @@ Options:
   --showfile emit diffed file position, not input file position
   -f, --file treat FILE as regular source file
   --subjective, --strict enable more subjective tests
+  --list-types   list the possible message types
   --types TYPE(,TYPE2...)show only these comma separated message types
   --ignore TYPE(,TYPE2...)   ignore various comma separated message types
+  --show-types   show the specific message type in the output
   --max-line-length=nset the maximum line length, if exceeded, warn
   --min-conf-desc-length=n   set the min description length, if shorter, warn
-  --show-types   show the message "types" in the output
   --root=PATHPATH to the kernel tree root
   --no-summary   suppress the per-file summary
   --mailback only produce a report in case of warnings/errors
@@ -106,6 +108,37 @@ EOM
exit($exitcode);
 }
 
+sub uniq {
+   my %seen;
+   return grep { !$seen{$_}++ } @_;
+}
+
+sub list_types {
+   my ($exitcode) = @_;
+
+   my $count = 0;
+
+   local $/ = undef;
+
+   open(my $script, '<', abs_path($P)) or
+   die "$P: Can't read '$P' $!\n";
+
+   my $text = <$script>;
+   close($script);
+
+   my @types = ();
+   for ($text =~ /\b(?:(?:CHK|WARN|ERROR)\s*\(\s*"([^"]+)")/g) {
+   push (@types, $_);
+   }
+   @types = sort(uniq(@types));
+   print("#\tMessage type\n\n");
+   foreach my $type (@types) {
+   print(++$count . "\t" . $type . "\n");
+   }
+
+   exit($exitcode);
+}
+
 my $conf = which_conf($configuration_file);
 if (-f $conf) {
my @conf_args;
@@ -146,6 +179,7 @@ GetOptions(
'ignore=s'  => \@ignore,
'types=s'   => \@use,
'show-types!'   => \$show_types,
+   'list-types!'   => \$list_types,
'max-line-length=i' => \$max_line_length,
'min-conf-desc-length=i' => \$min_conf_desc_length,
'root=s'=> \$root,
@@ -166,6 +200,8 @@ GetOptions(
 
 help(0) if ($help);
 
+list_types(0) if ($list_types);
+
 $fix = 1 if ($fix_inplace);
 $check_orig = $check;
 
-- 
2.8.0.rc4.16.g56331f8

[PATCH 2/2] checkpatch: Add --list-types to show message types to show or ignore

2016-04-12 Thread Joe Perches

The message types are not currently knowable without reading the code.
Add a mechanism to see what they are.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c87913f..abcafdb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -33,6 +33,7 @@ my $summary = 1;
 my $mailback = 0;
 my $summary_file = 0;
 my $show_types = 0;
+my $list_types = 0;
 my $fix = 0;
 my $fix_inplace = 0;
 my $root;
@@ -70,11 +71,12 @@ Options:
   --showfile emit diffed file position, not input file position
   -f, --file treat FILE as regular source file
   --subjective, --strict enable more subjective tests
+  --list-types   list the possible message types
   --types TYPE(,TYPE2...)show only these comma separated message types
   --ignore TYPE(,TYPE2...)   ignore various comma separated message types
+  --show-types   show the specific message type in the output
   --max-line-length=nset the maximum line length, if exceeded, warn
   --min-conf-desc-length=n   set the min description length, if shorter, warn
-  --show-types   show the message "types" in the output
   --root=PATHPATH to the kernel tree root
   --no-summary   suppress the per-file summary
   --mailback only produce a report in case of warnings/errors
@@ -106,6 +108,37 @@ EOM
exit($exitcode);
 }
 
+sub uniq {
+   my %seen;
+   return grep { !$seen{$_}++ } @_;
+}
+
+sub list_types {
+   my ($exitcode) = @_;
+
+   my $count = 0;
+
+   local $/ = undef;
+
+   open(my $script, '<', abs_path($P)) or
+   die "$P: Can't read '$P' $!\n";
+
+   my $text = <$script>;
+   close($script);
+
+   my @types = ();
+   for ($text =~ /\b(?:(?:CHK|WARN|ERROR)\s*\(\s*"([^"]+)")/g) {
+   push (@types, $_);
+   }
+   @types = sort(uniq(@types));
+   print("#\tMessage type\n\n");
+   foreach my $type (@types) {
+   print(++$count . "\t" . $type . "\n");
+   }
+
+   exit($exitcode);
+}
+
 my $conf = which_conf($configuration_file);
 if (-f $conf) {
my @conf_args;
@@ -146,6 +179,7 @@ GetOptions(
'ignore=s'  => \@ignore,
'types=s'   => \@use,
'show-types!'   => \$show_types,
+   'list-types!'   => \$list_types,
'max-line-length=i' => \$max_line_length,
'min-conf-desc-length=i' => \$min_conf_desc_length,
'root=s'=> \$root,
@@ -166,6 +200,8 @@ GetOptions(
 
 help(0) if ($help);
 
+list_types(0) if ($list_types);
+
 $fix = 1 if ($fix_inplace);
 $check_orig = $check;
 
-- 
2.8.0.rc4.16.g56331f8

[PATCH 1/2] checkpatch: Advertise the --fix and --fix-inplace options more

2016-04-12 Thread Joe Perches

The --fix option is relatively unknown and underutilized.

Add some text to show that it's available when style defects are found.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3d9c34..c87913f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5940,6 +5940,14 @@ sub process {
}
 
if ($quiet == 0) {
+   # If there were any defects found and not already fixing them
+   if (!$clean and !$fix) {
+   print << "EOM"
+
+NOTE: For some of the reported defects, checkpatch may be able to
+  mechanically convert to the typical style using --fix or --fix-inplace.
+EOM
+   }
# If there were whitespace errors which cleanpatch can fix
# then suggest that.
if ($rpt_cleaners) {
-- 
2.8.0.rc4.16.g56331f8

Re: [PATCH RFC] select_idle_sibling experiments

2016-04-12 Thread Mike Galbraith

On Tue, 2016-04-12 at 22:45 +0100, Matt Fleming wrote:
> On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
> > 
> > [ nohz throttling patch ]
> > 
> > I tested the nohz throttle two different ways, first with schbench's
> > pipe simulation, it's easily 8% faster with messages bouncing between
> > cpus.
> > 
> > In production it's hard to pick a single number because the benchmarks
> > produce latency curves as the workload scales up in RPS.  The benefits
> > range from 2-9% depending on the metric.  It's a nice win, and I'd love to
> > see it go in.
> 
> Do we have any idea what the tradeoff is against power consumption for
> throttling nohz?

That's measurable with the built in super duper watt meter gizmo
(turbostat).  It should be dinky but existent, could be given an off
button for particularly attentive laptop drivers to poke.  Servers
drivers are unlikely to care given the performance win.

-Mike

Re: [PATCH RFC] select_idle_sibling experiments

2016-04-12 Thread Mike Galbraith

On Tue, 2016-04-12 at 22:45 +0100, Matt Fleming wrote:
> On Sat, 09 Apr, at 01:30:34PM, Chris Mason wrote:
> > 
> > [ nohz throttling patch ]
> > 
> > I tested the nohz throttle two different ways, first with schbench's
> > pipe simulation, it's easily 8% faster with messages bouncing between
> > cpus.
> > 
> > In production it's hard to pick a single number because the benchmarks
> > produce latency curves as the workload scales up in RPS.  The benefits
> > range from 2-9% depending on the metric.  It's a nice win, and I'd love to
> > see it go in.
> 
> Do we have any idea what the tradeoff is against power consumption for
> throttling nohz?

That's measurable with the built in super duper watt meter gizmo
(turbostat).  It should be dinky but existent, could be given an off
button for particularly attentive laptop drivers to poke.  Servers
drivers are unlikely to care given the performance win.

-Mike

This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-12 Thread Josh Poimboeuf

On Thu, Feb 04, 2016 at 08:45:35PM +0100, Denys Vlasenko wrote:
> Sometimes gcc mysteriously doesn't inline
> very small functions we expect to be inlined. See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
> 
> With this .config:
> http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
> the following functions get deinlined many times.
> Examples of disassembly:
> 
>  (12 copies, 51 calls):
>66 8b 07mov(%rdi),%ax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>86 e0   xchg   %ah,%al
>5d  pop%rbp
>c3  retq
> 
>  (12 copies, 135 calls):
>8b 07   mov(%rdi),%eax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>0f c8   bswap  %eax
>5d  pop%rbp
>c3  retq
> 
>  (2 copies, 20 calls):
>48 8b 07mov(%rdi),%rax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>48 0f c8bswap  %rax
>5d  pop%rbp
>c3  retq
> 
> <__swab16p> (16 copies, 146 calls):
>55  push   %rbp
>89 f8   mov%edi,%eax
>86 e0   xchg   %ah,%al
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab32p> (43 copies, ~560 calls):
>55  push   %rbp
>89 f8   mov%edi,%eax
>0f c8   bswap  %eax
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab64p> (21 copies, 119 calls):
>55  push   %rbp
>48 89 f8mov%rdi,%rax
>48 0f c8bswap  %rax
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab32s> (6 copies, 47 calls):
>8b 07   mov(%rdi),%eax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>0f c8   bswap  %eax
>89 07   mov%eax,(%rdi)
>5d  pop%rbp
>c3  retq
> 
> This patch fixes this via s/inline/__always_inline/.
> Code size decrease after the patch is ~4.5k:
> 
> text data  bss   dec hex filename
> 92202377 20826112 36417536 149446025 8e85d89 vmlinux
> 92197848 20826112 36417536 149441496 8e84bd8 vmlinux5_swap_after
> 
> Signed-off-by: Denys Vlasenko 
> Cc: Ingo Molnar 
> Cc: Thomas Graf 
> Cc: Peter Zijlstra 
> Cc: David Rientjes 
> Cc: Andrew Morton 
> Cc: linux-kernel@vger.kernel.org
> ---
>  include/uapi/linux/byteorder/big_endian.h| 24 
>  include/uapi/linux/byteorder/little_endian.h | 24 
>  include/uapi/linux/swab.h| 10 +-
>  3 files changed, 29 insertions(+), 29 deletions(-)

Hi,

This patch seems to trigger a gcc bug which can produce corrupt code.  I
discovered it when investigating an objtool warning reported by kbuild
bot:

  http://www.spinics.net/lists/linux-scsi/msg95481.html

>From the disassembly of drivers/scsi/qla2xxx/qla_attr.o:

2f53 :
2f53:   55  push   %rbp
2f54:   48 89 e5mov%rsp,%rbp

2f57 :
2f57:   55  push   %rbp
2f58:   b9 e8 00 00 00  mov$0xe8,%ecx
2f5d:   48 89 e5mov%rsp,%rbp
...

Note that qla2x00_get_host_fabric_name() is inexplicably truncated after
setting up the frame pointer.  It falls through to the next function, which is
very wrong.

I can recreate it with either gcc 5.3.1 or gcc 6.0 on linus/master with
the .config from the above link.

The call chain which appears to trigger the problem is:

qla2x00_get_host_fabric_name()
  wwn_to_u64()
get_unaligned_be64()
  be64_to_cpup()
__be64_to_cpup() <- changed to __always_inline by this patch

It occurs with the combination of the following two recent commits:

- bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some 
byteswap operations")
- ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")

I can confirm that reverting either patch makes the problem go away.
I'm planning on opening a gcc bug tomorrow.

> -static inline __u64 __be64_to_cpup(const __be64 *p)
> +static __always_inline __u64

This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

2016-04-12 Thread Josh Poimboeuf

On Thu, Feb 04, 2016 at 08:45:35PM +0100, Denys Vlasenko wrote:
> Sometimes gcc mysteriously doesn't inline
> very small functions we expect to be inlined. See
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
> 
> With this .config:
> http://busybox.net/~vda/kernel_config_OPTIMIZE_INLINING_and_Os,
> the following functions get deinlined many times.
> Examples of disassembly:
> 
>  (12 copies, 51 calls):
>66 8b 07mov(%rdi),%ax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>86 e0   xchg   %ah,%al
>5d  pop%rbp
>c3  retq
> 
>  (12 copies, 135 calls):
>8b 07   mov(%rdi),%eax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>0f c8   bswap  %eax
>5d  pop%rbp
>c3  retq
> 
>  (2 copies, 20 calls):
>48 8b 07mov(%rdi),%rax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>48 0f c8bswap  %rax
>5d  pop%rbp
>c3  retq
> 
> <__swab16p> (16 copies, 146 calls):
>55  push   %rbp
>89 f8   mov%edi,%eax
>86 e0   xchg   %ah,%al
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab32p> (43 copies, ~560 calls):
>55  push   %rbp
>89 f8   mov%edi,%eax
>0f c8   bswap  %eax
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab64p> (21 copies, 119 calls):
>55  push   %rbp
>48 89 f8mov%rdi,%rax
>48 0f c8bswap  %rax
>48 89 e5mov%rsp,%rbp
>5d  pop%rbp
>c3  retq
> 
> <__swab32s> (6 copies, 47 calls):
>8b 07   mov(%rdi),%eax
>55  push   %rbp
>48 89 e5mov%rsp,%rbp
>0f c8   bswap  %eax
>89 07   mov%eax,(%rdi)
>5d  pop%rbp
>c3  retq
> 
> This patch fixes this via s/inline/__always_inline/.
> Code size decrease after the patch is ~4.5k:
> 
> text data  bss   dec hex filename
> 92202377 20826112 36417536 149446025 8e85d89 vmlinux
> 92197848 20826112 36417536 149441496 8e84bd8 vmlinux5_swap_after
> 
> Signed-off-by: Denys Vlasenko 
> Cc: Ingo Molnar 
> Cc: Thomas Graf 
> Cc: Peter Zijlstra 
> Cc: David Rientjes 
> Cc: Andrew Morton 
> Cc: linux-kernel@vger.kernel.org
> ---
>  include/uapi/linux/byteorder/big_endian.h| 24 
>  include/uapi/linux/byteorder/little_endian.h | 24 
>  include/uapi/linux/swab.h| 10 +-
>  3 files changed, 29 insertions(+), 29 deletions(-)

Hi,

This patch seems to trigger a gcc bug which can produce corrupt code.  I
discovered it when investigating an objtool warning reported by kbuild
bot:

  http://www.spinics.net/lists/linux-scsi/msg95481.html

>From the disassembly of drivers/scsi/qla2xxx/qla_attr.o:

2f53 :
2f53:   55  push   %rbp
2f54:   48 89 e5mov%rsp,%rbp

2f57 :
2f57:   55  push   %rbp
2f58:   b9 e8 00 00 00  mov$0xe8,%ecx
2f5d:   48 89 e5mov%rsp,%rbp
...

Note that qla2x00_get_host_fabric_name() is inexplicably truncated after
setting up the frame pointer.  It falls through to the next function, which is
very wrong.

I can recreate it with either gcc 5.3.1 or gcc 6.0 on linus/master with
the .config from the above link.

The call chain which appears to trigger the problem is:

qla2x00_get_host_fabric_name()
  wwn_to_u64()
get_unaligned_be64()
  be64_to_cpup()
__be64_to_cpup() <- changed to __always_inline by this patch

It occurs with the combination of the following two recent commits:

- bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining of some 
byteswap operations")
- ef3fb2422ffe ("scsi: fc: use get/put_unaligned64 for wwn access")

I can confirm that reverting either patch makes the problem go away.
I'm planning on opening a gcc bug tomorrow.

> -static inline __u64 __be64_to_cpup(const __be64 *p)
> +static __always_inline __u64 __be64_to_cpup(const __be64 *p)
>  {
>   return __swab64p((__u64 *)p);
>  }

-- 
Josh

Re: TCP reaching to maximum throughput after a long time

2016-04-12 Thread Eric Dumazet

On Tue, 2016-04-12 at 20:08 -0700, Yuchung Cheng wrote:

> based on the prev thread I propose we disable hystart ack-train. It is
> brittle under various circumstances. We've disabled that at Google for
> years.

Right, but because we also use sch_fq packet scheduler and pacing ;)

Re: TCP reaching to maximum throughput after a long time

2016-04-12 Thread Eric Dumazet

On Tue, 2016-04-12 at 20:08 -0700, Yuchung Cheng wrote:

> based on the prev thread I propose we disable hystart ack-train. It is
> brittle under various circumstances. We've disabled that at Google for
> years.

Right, but because we also use sch_fq packet scheduler and pacing ;)

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

2016-04-12 Thread Andrew Vagin

On Tue, Apr 12, 2016 at 09:03:39AM +0800, kbuild test robot wrote:
> Hi Andrey,
> 
> [auto build test ERROR on v4.6-rc3]
> [also build test ERROR on next-20160411]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Andrey-Vagin/task_diag-add-a-new-interface-to-get-information-about-processes-v3/20160412-074109
> config: microblaze-allmodconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=microblaze 
> 
> Note: the 
> linux-review/Andrey-Vagin/task_diag-add-a-new-interface-to-get-information-about-processes-v3/20160412-074109
>  HEAD 2e0f174ce7e6fddc8fdd89f3dbb8d990626358a0 builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
> >> fs/proc/task_diag.c:139:19: error: field 'tgid' has incomplete type
>  struct tgid_iter tgid;
>   ^
>fs/proc/task_diag.c: In function 'iter_start':
> >> fs/proc/task_diag.c:187:3: error: implicit declaration of function 
> >> 'next_tgid' [-Werror=implicit-function-declaration]
>   iter->tgid = next_tgid(iter->ns, iter->tgid);
>   ^
>cc1: some warnings being treated as errors
>

Unfortunately I forgot to include fs/proc/internal.h here. It will be
included in the 6-th patch. I will fix this issue in a final version.

Thanks,
Andrew

Re: [PATCH 04/15] task_diag: add a new interface to get information about tasks (v4)

2016-04-12 Thread Andrew Vagin

On Tue, Apr 12, 2016 at 09:03:39AM +0800, kbuild test robot wrote:
> Hi Andrey,
> 
> [auto build test ERROR on v4.6-rc3]
> [also build test ERROR on next-20160411]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Andrey-Vagin/task_diag-add-a-new-interface-to-get-information-about-processes-v3/20160412-074109
> config: microblaze-allmodconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=microblaze 
> 
> Note: the 
> linux-review/Andrey-Vagin/task_diag-add-a-new-interface-to-get-information-about-processes-v3/20160412-074109
>  HEAD 2e0f174ce7e6fddc8fdd89f3dbb8d990626358a0 builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
> >> fs/proc/task_diag.c:139:19: error: field 'tgid' has incomplete type
>  struct tgid_iter tgid;
>   ^
>fs/proc/task_diag.c: In function 'iter_start':
> >> fs/proc/task_diag.c:187:3: error: implicit declaration of function 
> >> 'next_tgid' [-Werror=implicit-function-declaration]
>   iter->tgid = next_tgid(iter->ns, iter->tgid);
>   ^
>cc1: some warnings being treated as errors
>

Unfortunately I forgot to include fs/proc/internal.h here. It will be
included in the 6-th patch. I will fix this issue in a final version.

Thanks,
Andrew

Re: Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

2016-04-12 Thread Jianyu Zhan

On Wed, Apr 13, 2016 at 11:11 AM, Jianyu Zhan  wrote:
>
> So  I suspect there is a possible race:
>
>
>Parent:
>
>sys_execve
>  do_execve
>do_execve_common
>  search_binary_handler
> load_elf_binary
>   start_thread
> start_thread_common
>free_thread_xstate(current)
>  fpu_free
> fpu->state = NULL
>
>
> Child:
>
> sys_clone
>   do_fork
>  copy_process
> dup_task_struct
>prepare_to_copy
>   unlazy_fpu
>  __save_init_fpu
>fpu_save_init
>  fpu_xsave(fpu)   < fpu->sate is NULL,
> so cause a
> NULL
> dereference.
>

Hmm,  I am wrong, it is not Parent vs Child.

It is :   Parent  executes  sys_execuve,  and then right after that,
executes sys_clone.


 Regards,
 Jianyu Zhan

Re: Possible race in copy of fpu->state in copy_process against the exeve'ing parent?

2016-04-12 Thread Jianyu Zhan

On Wed, Apr 13, 2016 at 11:11 AM, Jianyu Zhan  wrote:
>
> So  I suspect there is a possible race:
>
>
>Parent:
>
>sys_execve
>  do_execve
>do_execve_common
>  search_binary_handler
> load_elf_binary
>   start_thread
> start_thread_common
>free_thread_xstate(current)
>  fpu_free
> fpu->state = NULL
>
>
> Child:
>
> sys_clone
>   do_fork
>  copy_process
> dup_task_struct
>prepare_to_copy
>   unlazy_fpu
>  __save_init_fpu
>fpu_save_init
>  fpu_xsave(fpu)   < fpu->sate is NULL,
> so cause a
> NULL
> dereference.
>

Hmm,  I am wrong, it is not Parent vs Child.

It is :   Parent  executes  sys_execuve,  and then right after that,
executes sys_clone.


 Regards,
 Jianyu Zhan

Re: sched: tweak select_idle_sibling to look for idle threads

2016-04-12 Thread Mike Galbraith

On Tue, 2016-04-12 at 16:07 -0400, Chris Mason wrote:

> I think that if we're worried about the cost of the idle scan for this
> workload, find_idlest_group() is either going to hurt much more, or not
> search enough CPUs to find the idle one.

find_idlest_group()?  No no no, that's not what I mean at all.

wake_wide() identifies loads that really want to spread out, thus turns
off affine wakeups.  We still call select_idle_sibling(), only
difference being that target is the original cpu, not the waking cpu. 
 Given making that wide connection bidirectional helped FB's load, it
seems reasonable that passing wide information to select_idle_sibling()
would have a good chance of hitting the candidate that stands to gain
from a full socket scan, while also keeping that cache scrambling scan
far away from the rest. 

> But I'm happy to try patches or other ideas, I have a fixed version of
> the bitmap one going through production benchmarks now.

Making that wide/full search cheap is still good, because wake_wide()
also identifies interrupt sources that are waking many, so cheap wide
search should increase utilization there as well.  The thought was to
just make the wide thing have a tad wider effect on what it already
does affect.. and hope that doesn't demolish anything.

-Mike

Re: sched: tweak select_idle_sibling to look for idle threads

2016-04-12 Thread Mike Galbraith

On Tue, 2016-04-12 at 16:07 -0400, Chris Mason wrote:

> I think that if we're worried about the cost of the idle scan for this
> workload, find_idlest_group() is either going to hurt much more, or not
> search enough CPUs to find the idle one.

find_idlest_group()?  No no no, that's not what I mean at all.

wake_wide() identifies loads that really want to spread out, thus turns
off affine wakeups.  We still call select_idle_sibling(), only
difference being that target is the original cpu, not the waking cpu. 
 Given making that wide connection bidirectional helped FB's load, it
seems reasonable that passing wide information to select_idle_sibling()
would have a good chance of hitting the candidate that stands to gain
from a full socket scan, while also keeping that cache scrambling scan
far away from the rest. 

> But I'm happy to try patches or other ideas, I have a fixed version of
> the bitmap one going through production benchmarks now.

Making that wide/full search cheap is still good, because wake_wide()
also identifies interrupt sources that are waking many, so cheap wide
search should increase utilization there as well.  The thought was to
just make the wide thing have a tad wider effect on what it already
does affect.. and hope that doesn't demolish anything.

-Mike

Re: [PATCH v2 1/5] dax: add dax_get_unmapped_area for pmd mappings

2016-04-12 Thread Matthew Wilcox

On Tue, Apr 12, 2016 at 02:39:15PM -0600, Toshi Kani wrote:
> + * When the target file is not a DAX file, @addr is specified, the
> + * request is not suitable for pmd mappings, or mm->get_unmapped_area()
> + * failed with extended @len, it simply calls the default handler,
> + * mm->get_unmapped_area(), with the original arguments.

I think you can lose this paragraph.  It describes what the function
does, not why it does it ... and we can see what the function does from
reading the code.

> +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;
> +
> + if (IS_ENABLED(CONFIG_FS_DAX_PMD) &&
> + filp && !addr && IS_DAX(filp->f_mapping->host)) {
> + off = pgoff << PAGE_SHIFT;
> + off_end = off + len;
> + off_pmd = round_up(off, PMD_SIZE);
> +
> + if ((off_end > off_pmd) && ((off_end - off_pmd) >= PMD_SIZE)) {
> + len_pmd = len + PMD_SIZE;
> +
> + addr_pmd = current->mm->get_unmapped_area(
> + filp, addr, len_pmd, pgoff, flags);
> +
> + if (!IS_ERR_VALUE(addr_pmd)) {
> + addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);
> + return addr_pmd;
> + }
> + }
> + }
> +
> + return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
> +}

I think this is one of those functions which is actually improved with
gotos, purely to reduce the indentation level.

unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags)
{
unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;

if (!IS_ENABLED(CONFIG_FS_DAX_PMD) ||
!filp || addr || !IS_DAX(filp->f_mapping->host))
goto out;

off = pgoff << PAGE_SHIFT;
off_end = off + len;
off_pmd = round_up(off, PMD_SIZE);
if ((off_end <= off_pmd) || ((off_end - off_pmd) < PMD_SIZE))
goto out;

len_pmd = len + PMD_SIZE;
addr_pmd = current->mm->get_unmapped_area(filp, addr, len_pmd,
pgoff, flags);

if (!IS_ERR_VALUE(addr_pmd)) {
addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);
return addr_pmd;
}

 out:
return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
}

Now ... back to the original version, some questions:

> +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;
> +
> + if (IS_ENABLED(CONFIG_FS_DAX_PMD) &&
> + filp && !addr && IS_DAX(filp->f_mapping->host)) {
> + off = pgoff << PAGE_SHIFT;
> + off_end = off + len;

Can off + len wrap here, or did that get checked earlier?

> + off_pmd = round_up(off, PMD_SIZE);
> +
> + if ((off_end > off_pmd) && ((off_end - off_pmd) >= PMD_SIZE)) {

We're only going to look for a PMD-aligned mapping if the mapping is at
least double PMD_SIZE?  I don't understand that decision.  Seems to me
that if I ask to map offset 4MB, length 2MB, I should get a PMD-aligned
mapping.

Speaking of offset, we don't have any checks that offset is a multiple
of PMD_SIZE.  I know that theoretically we could map offset 1.5MB, length
3MB and see the first 0.5MB filled with small pages, then the next 2MB
filled with one large page, and the tail filled with small pages, but I
think we're better off only looking for PMD-alignment if the user asked
for an aligned offset in the file.

> + len_pmd = len + PMD_SIZE;
> +
> + addr_pmd = current->mm->get_unmapped_area(
> + filp, addr, len_pmd, pgoff, flags);
> +
> + if (!IS_ERR_VALUE(addr_pmd)) {
> + addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);

... then you wouldn't need this calculation ;-)

> + return addr_pmd;
> + }

Re: [PATCH v2 1/5] dax: add dax_get_unmapped_area for pmd mappings

2016-04-12 Thread Matthew Wilcox

On Tue, Apr 12, 2016 at 02:39:15PM -0600, Toshi Kani wrote:
> + * When the target file is not a DAX file, @addr is specified, the
> + * request is not suitable for pmd mappings, or mm->get_unmapped_area()
> + * failed with extended @len, it simply calls the default handler,
> + * mm->get_unmapped_area(), with the original arguments.

I think you can lose this paragraph.  It describes what the function
does, not why it does it ... and we can see what the function does from
reading the code.

> +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;
> +
> + if (IS_ENABLED(CONFIG_FS_DAX_PMD) &&
> + filp && !addr && IS_DAX(filp->f_mapping->host)) {
> + off = pgoff << PAGE_SHIFT;
> + off_end = off + len;
> + off_pmd = round_up(off, PMD_SIZE);
> +
> + if ((off_end > off_pmd) && ((off_end - off_pmd) >= PMD_SIZE)) {
> + len_pmd = len + PMD_SIZE;
> +
> + addr_pmd = current->mm->get_unmapped_area(
> + filp, addr, len_pmd, pgoff, flags);
> +
> + if (!IS_ERR_VALUE(addr_pmd)) {
> + addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);
> + return addr_pmd;
> + }
> + }
> + }
> +
> + return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
> +}

I think this is one of those functions which is actually improved with
gotos, purely to reduce the indentation level.

unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
unsigned long len, unsigned long pgoff, unsigned long flags)
{
unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;

if (!IS_ENABLED(CONFIG_FS_DAX_PMD) ||
!filp || addr || !IS_DAX(filp->f_mapping->host))
goto out;

off = pgoff << PAGE_SHIFT;
off_end = off + len;
off_pmd = round_up(off, PMD_SIZE);
if ((off_end <= off_pmd) || ((off_end - off_pmd) < PMD_SIZE))
goto out;

len_pmd = len + PMD_SIZE;
addr_pmd = current->mm->get_unmapped_area(filp, addr, len_pmd,
pgoff, flags);

if (!IS_ERR_VALUE(addr_pmd)) {
addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);
return addr_pmd;
}

 out:
return current->mm->get_unmapped_area(filp, addr, len, pgoff, flags);
}

Now ... back to the original version, some questions:

> +unsigned long dax_get_unmapped_area(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff, unsigned long flags)
> +{
> + unsigned long off, off_end, off_pmd, len_pmd, addr_pmd;
> +
> + if (IS_ENABLED(CONFIG_FS_DAX_PMD) &&
> + filp && !addr && IS_DAX(filp->f_mapping->host)) {
> + off = pgoff << PAGE_SHIFT;
> + off_end = off + len;

Can off + len wrap here, or did that get checked earlier?

> + off_pmd = round_up(off, PMD_SIZE);
> +
> + if ((off_end > off_pmd) && ((off_end - off_pmd) >= PMD_SIZE)) {

We're only going to look for a PMD-aligned mapping if the mapping is at
least double PMD_SIZE?  I don't understand that decision.  Seems to me
that if I ask to map offset 4MB, length 2MB, I should get a PMD-aligned
mapping.

Speaking of offset, we don't have any checks that offset is a multiple
of PMD_SIZE.  I know that theoretically we could map offset 1.5MB, length
3MB and see the first 0.5MB filled with small pages, then the next 2MB
filled with one large page, and the tail filled with small pages, but I
think we're better off only looking for PMD-alignment if the user asked
for an aligned offset in the file.

> + len_pmd = len + PMD_SIZE;
> +
> + addr_pmd = current->mm->get_unmapped_area(
> + filp, addr, len_pmd, pgoff, flags);
> +
> + if (!IS_ERR_VALUE(addr_pmd)) {
> + addr_pmd += (off - addr_pmd) & (PMD_SIZE - 1);

... then you wouldn't need this calculation ;-)

> + return addr_pmd;
> + }

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 2144 matches

Mail list logo