Finance Department | 24 Oct 13:59 2014
Picon

Payment

Dear Recipient,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) with reference number
77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.

Gloria Peter
Richard Zhu | 24 Oct 04:36 2014

[PATCH V2]PCI: imx6: Wait the clocks to stabilize after ref_en

Fabio suggested to resend this patch only, since he notice that
the kernel does not boot anymore since commit  3fce0e882f61
(PCI: imx6: Delay enabling reference clock for SS until it stabilizes)
on a system that does not pass the PCI gpio reset in the dtb. This causes
a regression on mx6 nitrogen boards.

Add "Signed-off-by: Lucas Stach <l.stach <at> pengutronix.de>" into the patch.

[PATCH V2] PCI: imx6: Wait the clocks to stabilize after ref_en
---
 drivers/pci/host/pci-imx6.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
Richard Zhu | 24 Oct 04:30 2014

[PATCH V1]PCI: imx6: Wait the clocks to stabilize after ref_en

Fabio suggested to resend this patch only, because that he notice that
the kernel does not boot anymore since commit  3fce0e882f61
(PCI: imx6: Delay enabling reference clock for SS until it stabilizes)
on a system that does not pass the PCI gpio reset in the dtb. This causes
a regression on mx6 nitrogen boards.

[PATCH V1] PCI: imx6: Wait the clocks to stabilize after ref_en
---
 drivers/pci/host/pci-imx6.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Prarit Bhargava | 23 Oct 20:22 2014
Picon

[PATCH V2] pci, add sysfs numa_node write function

Some new drivers, such as the Intel QAT driver, drivers/crypto/qat,
require that a specific node be assigned to the device in order to
achieve maximum performance for the device, and will fail to load if the
device has NUMA_NO_NODE.  Users can in some cases, with additional
information provided by vendor support, determine what the correct numa
node is supposed to be.  In the cases a quick hack of the driver results
in a function QAT device.

In theory, it should be possible to map a PCI device to a PCI root bridge
to a specific node, however, in practice it is not possible.  Nodes may
have multiple PCI root bridges, may share multiple PCI root bridges, or
may not have an active root bridge assigned.  Hardware manufacturers may
specifically have designed systems without numa node to PCI root bridge
mappings.  Without assistance from some hardware reporting mechanism
(SMBIOS, ACPI, etc.) there is no reliable way to determine the numa node
for a PCI bridge or device.  Typically this numa mapping is done via the
ACPI _PXM values in the ACPI tables, however, there are many systems out
there that do not populate the ACPI _PXM entries and therefore do not have
correct PCI device numa_node values.

Hardware vendors are accepting of reported bugs for the ACPI _PXM entries,
but production fixes are typically seen in 6 months to a year and in
some past cases, never.

This patch introduces a mechanism to allow a user that knows the correct
value of the numa node to set it via sysfs.  As suggested by Alexander
and Bjorn, the setting of the value issues a loud FW_BUG message and
TAINTS notify the user that the issue really is a firmware bug.

To use this, one can do
(Continue reading)

Prarit Bhargava | 23 Oct 20:20 2014
Picon

[PATCH V2] pci, add sysfs numa_node write function

Some new drivers, such as the Intel QAT driver, drivers/crypto/qat,
require that a specific node be assigned to the device in order to
achieve maximum performance for the device, and will fail to load if the
device has NUMA_NO_NODE.  Users can in some cases, with additional
information provided by vendor support, determine what the correct numa
node is supposed to be.  In the cases a quick hack of the driver results
in a function QAT device.

In theory, it should be possible to map a PCI device to a PCI root bridge
to a specific node, however, in practice it is not possible.  Nodes may
have multiple PCI root bridges, may share multiple PCI root bridges, or
may not have an active root bridge assigned.  Hardware manufacturers may
specifically have designed systems without numa node to PCI root bridge
mappings.  Without assistance from some hardware reporting mechanism
(SMBIOS, ACPI, etc.) there is no reliable way to determine the numa node
for a PCI bridge or device.  Typically this numa mapping is done via the
ACPI _PXM values in the ACPI tables, however, there are many systems out
there that do not populate the ACPI _PXM entries and therefore do not have
correct PCI device numa_node values.

Hardware vendors are accepting of reported bugs for the ACPI _PXM entries,
but production fixes are typically seen in 6 months to a year and in
some past cases, never.

This patch introduces a mechanism to allow a user that knows the correct
value of the numa node to set it via sysfs.  As suggested by Alexander
and Bjorn, the setting of the value issues a loud FW_BUG message and
TAINTS notify the user that the issue really is a firmware bug.

To use this, one can do
(Continue reading)

Andreas Hartmann | 23 Oct 19:33 2014
Picon

Re: Hard and silent lock up since linux 3.14 with PCIe pass through (vfio)

Alex Williamson wrote:
[...]
> If you use Bjorn's previous patch to disable VC save/restore and my
> patch to reorder the reset mechanisms, does echo 1 > reset for the sysfs
> entry for the device also still cause a hang?

Yes - it's hanging too (w/ vfio bound to the device - didn't test other
possibilities).

Regards,
Andreas
Andreas Hartmann | 23 Oct 19:12 2014
Picon

Re: Hard and silent lock up since linux 3.14 with PCIe pass through (vfio)

Alex Williamson wrote:
> On Thu, 2014-10-23 at 18:00 +0200, Andreas Hartmann wrote:
>> Alex Williamson wrote:
>>> On Wed, 2014-10-22 at 18:22 +0200, Andreas Hartmann wrote:
>>>> Alex Williamson wrote:
>>>>> --- a/drivers/pci/pci.c
>>>>> +++ b/drivers/pci/pci.c
>>>>>  <at>  <at>  -3308,15 +3308,15  <at>  <at>  static int __pci_dev_reset(struct pci_dev *dev, int prob
>>>>>         if (rc != -ENOTTY)
>>>>>                 goto done;
>>>>>  
>>>>> -       rc = pci_pm_reset(dev, probe);
>>>>> +       rc = pci_dev_reset_slot_function(dev, probe);
>>>>>         if (rc != -ENOTTY)
>>>>>                 goto done;
>>>>>  
>>>>> -       rc = pci_dev_reset_slot_function(dev, probe);
>>>>> +       rc = pci_parent_bus_reset(dev, probe);
>>>>>         if (rc != -ENOTTY)
>>>>>                 goto done;
>>>>>  
>>>>> -       rc = pci_parent_bus_reset(dev, probe);
>>>>> +       rc = pci_pm_reset(dev, probe);
>>>>>  done:
>>>>>         return rc;
>>>>>  }
>>>>
>>>> This way it's crashing with echo 1 > reset, too.
>>>
>>> Ok, so it's somehow related to doing a bus reset with virtual channel
(Continue reading)

Jingoo Han | 23 Oct 04:11 2014

[PATCH] PCI: rcar: make local symbol static

Make local symbol static, because this is used only in this file.

Signed-off-by: Jingoo Han <jg1.han <at> samsung.com>
---
 drivers/pci/host/pcie-rcar.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 61158e0..0df9b29 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
 <at>  <at>  -389,7 +389,7  <at>  <at>  static void rcar_pcie_add_bus(struct pci_bus *bus)
 	}
 }

-struct hw_pci rcar_pci = {
+static struct hw_pci rcar_pci = {
 	.setup          = rcar_pcie_setup,
 	.map_irq        = of_irq_parse_and_map_pci,
 	.ops            = &rcar_pcie_ops,
--

-- 
1.7.9.5

Jingoo Han | 23 Oct 04:10 2014

[PATCH] PCI: keystone: make local symbol static

Make local symbol static, because this is used only in this file.

Signed-off-by: Jingoo Han <jg1.han <at> samsung.com>
---
 drivers/pci/host/pci-keystone-dw.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-keystone-dw.c
index 34086ce..4a97cd1 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
 <at>  <at>  -201,7 +201,7  <at>  <at>  static int ks_dw_pcie_msi_map(struct irq_domain *domain, unsigned int irq,
 	return 0;
 }

-const struct irq_domain_ops ks_dw_pcie_msi_domain_ops = {
+static const struct irq_domain_ops ks_dw_pcie_msi_domain_ops = {
 	.map = ks_dw_pcie_msi_map,
 };

--

-- 
1.7.9.5

Lucas Stach | 22 Oct 14:31 2014
Picon

[PATCH] PCI / PM: handle failure to enable wakeup on PCIe PME

If the irqchip handling the PCIe PME interrupt is not able
to enable interrupt wakeup we should properly reflect this
in the PME suspend status.

This fixes a kernel warning on resume, where it would try
to disable the irq wakeup that failed to be activated while
suspending. The issue was introduced with 76cde7e49590
(PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle).

Reported-by: Richard Zhu <richard.zhu <at> freescale.com>
Signed-off-by: Lucas Stach <l.stach <at> pengutronix.de>
Tested-by: Richard Zhu <richard.zhu <at> freescale.com>
---
Trimmed warning on resume looks like this:
[  109.292736] WARNING: CPU: 0 PID: 609 at kernel/irq/manage.c:536 irq_set_irq_wake+0xc0/0xf8()
[  109.301193] Unbalanced IRQ 384 wake disable
[  109.305392] Modules linked in:
[  109.308502] CPU: 0 PID: 609 Comm: kworker/u2:9 Tainted: G        W      3.18.0-rc1-00009-g820df3d-dirty #268
[  109.318368] Workqueue: events_unbound async_run_entry_fn
[  109.323718] Backtrace:
[  109.326233] [<80012460>] (dump_backtrace) from [<80012744>] (show_stack+0x18/0x1c)
[  109.339616] [<8001272c>] (show_stack) from [<806d8dc8>] (dump_stack+0x8c/0xa4)
[  109.346885] [<806d8d3c>] (dump_stack) from [<8002a88c>] (warn_slowpath_common+0x70/0x94)
[  109.360773] [<8002a81c>] (warn_slowpath_common) from [<8002a8e8>] (warn_slowpath_fmt+0x38/0x40)
[  109.376334] [<8002a8b4>] (warn_slowpath_fmt) from [<8006c2a8>] (irq_set_irq_wake+0xc0/0xf8)
[  109.388351] [<8006c1e8>] (irq_set_irq_wake) from [<802f22cc>] (pcie_pme_resume+0x34/0x64)
[  109.402328] [<802f2298>] (pcie_pme_resume) from [<802f1590>] (resume_iter+0x44/0x50)
[  109.413742] [<802f154c>] (resume_iter) from [<803784d4>] (device_for_each_child+0x4c/0x78)
[  109.422039] [<80378488>] (device_for_each_child) from [<802f196c>] (pcie_port_device_resume+0x18/0x20)
[  109.436085] [<802f1954>] (pcie_port_device_resume) from [<802e6f40>] (pci_pm_resume+0x7c/0x10c)
(Continue reading)

Jingoo Han | 22 Oct 06:58 2014

[PATCH RESEND ] PCI: exynos: Add exynos prefix before add_pcie_port/pcie_init

The add_pcie_port/pcie_init functions are Exynos-specific.
Add exynos prefix to avoid collision in global name space.

Signed-off-by: Jingoo Han <jg1.han <at> samsung.com>
---
 drivers/pci/host/pci-exynos.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index c5d0ca3..902d7cd 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
 <at>  <at>  -509,8 +509,8  <at>  <at>  static struct pcie_host_ops exynos_pcie_host_ops = {
 	.host_init = exynos_pcie_host_init,
 };

-static int __init add_pcie_port(struct pcie_port *pp,
-				struct platform_device *pdev)
+static int __init exynos_add_pcie_port(struct pcie_port *pp,
+				       struct platform_device *pdev)
 {
 	int ret;

 <at>  <at>  -615,7 +615,7  <at>  <at>  static int __init exynos_pcie_probe(struct platform_device *pdev)
 		goto fail_bus_clk;
 	}

-	ret = add_pcie_port(pp, pdev);
+	ret = exynos_add_pcie_port(pp, pdev);
 	if (ret < 0)
(Continue reading)


Gmane