<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/powerpc/platforms, branch v3.15</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>powerpc/powernv: Reset root port in firmware</title>
<updated>2014-05-12T00:33:08+00:00</updated>
<author>
<name>Gavin Shan</name>
<email>gwshan@linux.vnet.ibm.com</email>
</author>
<published>2014-04-24T08:00:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=372cf1244d7c271806b83b32b09a1c8b1b31b353'/>
<id>372cf1244d7c271806b83b32b09a1c8b1b31b353</id>
<content type='text'>
Resetting root port has more stuff to do than that for PCIe switch
ports and we should have resetting root port done in firmware instead
of the kernel itself. The problem was introduced by commit 5b2e198e
("powerpc/powernv: Rework EEH reset").

Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gavin Shan &lt;gwshan@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Resetting root port has more stuff to do than that for PCIe switch
ports and we should have resetting root port done in firmware instead
of the kernel itself. The problem was introduced by commit 5b2e198e
("powerpc/powernv: Rework EEH reset").

Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gavin Shan &lt;gwshan@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ppc/powernv: Set the runlatch bits correctly for offline cpus</title>
<updated>2014-04-28T06:32:40+00:00</updated>
<author>
<name>Preeti U Murthy</name>
<email>preeti@linux.vnet.ibm.com</email>
</author>
<published>2014-04-11T10:31:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f203891117323dd31c11adcbba60452c933d604e'/>
<id>f203891117323dd31c11adcbba60452c933d604e</id>
<content type='text'>
Up until now we have been setting the runlatch bits for a busy CPU and
clearing it when a CPU enters idle state. The runlatch bit has thus
been consistent with the utilization of a CPU as long as the CPU is online.

However when a CPU is hotplugged out the runlatch bit is not cleared. It
needs to be cleared to indicate an unused CPU. Hence this patch has the
runlatch bit cleared for an offline CPU just before entering an idle state
and sets it immediately after it exits the idle state.

Signed-off-by: Preeti U Murthy &lt;preeti@linux.vnet.ibm.com&gt;
Acked-by: Paul Mackerras &lt;paulus@samba.org&gt;
Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Up until now we have been setting the runlatch bits for a busy CPU and
clearing it when a CPU enters idle state. The runlatch bit has thus
been consistent with the utilization of a CPU as long as the CPU is online.

However when a CPU is hotplugged out the runlatch bit is not cleared. It
needs to be cleared to indicate an unused CPU. Hence this patch has the
runlatch bit cleared for an offline CPU just before entering an idle state
and sets it immediately after it exits the idle state.

Signed-off-by: Preeti U Murthy &lt;preeti@linux.vnet.ibm.com&gt;
Acked-by: Paul Mackerras &lt;paulus@samba.org&gt;
Reviewed-by: Srivatsa S. Bhat &lt;srivatsa.bhat@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/pseries: Protect remove_memory() with device hotplug lock</title>
<updated>2014-04-28T06:32:14+00:00</updated>
<author>
<name>Li Zhong</name>
<email>zhong@linux.vnet.ibm.com</email>
</author>
<published>2014-04-10T08:25:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=42dbfc8649737cb622b2a7e02045401c4c09561c'/>
<id>42dbfc8649737cb622b2a7e02045401c4c09561c</id>
<content type='text'>
While testing memory hot-remove, I found following dead lock:

Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
It holds the memory_hotplug_mutex, and blocks when trying to remove file
"online" under dir memory499, in kernfs_drain(), at
        wait_event(root-&gt;deactivate_waitq,
                   atomic_read(&amp;kn-&gt;active) == KN_DEACTIVATED_BIAS);

Process #1120 is trying to online memory499 by
   echo 1 &gt; memory499/online

In .kernfs_fop_write, it uses kernfs_get_active() to increase
&amp;kn-&gt;active, thus blocking process #1141. While itself is blocked later
when trying to acquire memory_hotplug_mutex, which is held by process

The backtrace of both processes are shown below:

[&lt;c000000001b18600&gt;] 0xc000000001b18600
[&lt;c000000000015044&gt;] .__switch_to+0x144/0x200
[&lt;c000000000263ca4&gt;] .online_pages+0x74/0x7b0
[&lt;c00000000055b40c&gt;] .memory_subsys_online+0x9c/0x150
[&lt;c00000000053cbe8&gt;] .device_online+0xb8/0x120
[&lt;c00000000053cd04&gt;] .online_store+0xb4/0xc0
[&lt;c000000000538ce4&gt;] .dev_attr_store+0x64/0xa0
[&lt;c00000000030f4ec&gt;] .sysfs_kf_write+0x7c/0xb0
[&lt;c00000000030e574&gt;] .kernfs_fop_write+0x154/0x1e0
[&lt;c000000000268450&gt;] .vfs_write+0xe0/0x260
[&lt;c000000000269144&gt;] .SyS_write+0x64/0x110
[&lt;c000000000009ffc&gt;] syscall_exit+0x0/0x7c

[&lt;c000000001b18600&gt;] 0xc000000001b18600
[&lt;c000000000015044&gt;] .__switch_to+0x144/0x200
[&lt;c00000000030be14&gt;] .__kernfs_remove+0x204/0x300
[&lt;c00000000030d428&gt;] .kernfs_remove_by_name_ns+0x68/0xf0
[&lt;c00000000030fb38&gt;] .sysfs_remove_file_ns+0x38/0x60
[&lt;c000000000539354&gt;] .device_remove_attrs+0x54/0xc0
[&lt;c000000000539fd8&gt;] .device_del+0x158/0x250
[&lt;c00000000053a104&gt;] .device_unregister+0x34/0xa0
[&lt;c00000000055bc14&gt;] .unregister_memory_section+0x164/0x170
[&lt;c00000000024ee18&gt;] .__remove_pages+0x108/0x4c0
[&lt;c00000000004b590&gt;] .arch_remove_memory+0x60/0xc0
[&lt;c00000000026446c&gt;] .remove_memory+0x8c/0xe0
[&lt;c00000000007f9f4&gt;] .pseries_remove_memblock+0xd4/0x160
[&lt;c00000000007fcfc&gt;] .pseries_memory_notifier+0x27c/0x290
[&lt;c0000000008ae6cc&gt;] .notifier_call_chain+0x8c/0x100
[&lt;c0000000000d858c&gt;] .__blocking_notifier_call_chain+0x6c/0xe0
[&lt;c00000000071ddec&gt;] .of_property_notify+0x7c/0xc0
[&lt;c00000000071ed3c&gt;] .of_update_property+0x3c/0x1b0
[&lt;c0000000000756cc&gt;] .ofdt_write+0x3dc/0x740
[&lt;c0000000002f60fc&gt;] .proc_reg_write+0xac/0x110
[&lt;c000000000268450&gt;] .vfs_write+0xe0/0x260
[&lt;c000000000269144&gt;] .SyS_write+0x64/0x110
[&lt;c000000000009ffc&gt;] syscall_exit+0x0/0x7c

This patch uses lock_device_hotplug() to protect remove_memory() called
in pseries_remove_memblock(), which is also stated before function
remove_memory():

 * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
 * and online/offline operations before this call, as required by
 * try_offline_node().
 */
void __ref remove_memory(int nid, u64 start, u64 size)

With this lock held, the other process(#1120 above) trying to online the
memory block will retry the system call when calling
lock_device_hotplug_sysfs(), and finally find No such device error.

Signed-off-by: Li Zhong &lt;zhong@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While testing memory hot-remove, I found following dead lock:

Process #1141 is drmgr, trying to remove some memory, i.e. memory499.
It holds the memory_hotplug_mutex, and blocks when trying to remove file
"online" under dir memory499, in kernfs_drain(), at
        wait_event(root-&gt;deactivate_waitq,
                   atomic_read(&amp;kn-&gt;active) == KN_DEACTIVATED_BIAS);

Process #1120 is trying to online memory499 by
   echo 1 &gt; memory499/online

In .kernfs_fop_write, it uses kernfs_get_active() to increase
&amp;kn-&gt;active, thus blocking process #1141. While itself is blocked later
when trying to acquire memory_hotplug_mutex, which is held by process

The backtrace of both processes are shown below:

[&lt;c000000001b18600&gt;] 0xc000000001b18600
[&lt;c000000000015044&gt;] .__switch_to+0x144/0x200
[&lt;c000000000263ca4&gt;] .online_pages+0x74/0x7b0
[&lt;c00000000055b40c&gt;] .memory_subsys_online+0x9c/0x150
[&lt;c00000000053cbe8&gt;] .device_online+0xb8/0x120
[&lt;c00000000053cd04&gt;] .online_store+0xb4/0xc0
[&lt;c000000000538ce4&gt;] .dev_attr_store+0x64/0xa0
[&lt;c00000000030f4ec&gt;] .sysfs_kf_write+0x7c/0xb0
[&lt;c00000000030e574&gt;] .kernfs_fop_write+0x154/0x1e0
[&lt;c000000000268450&gt;] .vfs_write+0xe0/0x260
[&lt;c000000000269144&gt;] .SyS_write+0x64/0x110
[&lt;c000000000009ffc&gt;] syscall_exit+0x0/0x7c

[&lt;c000000001b18600&gt;] 0xc000000001b18600
[&lt;c000000000015044&gt;] .__switch_to+0x144/0x200
[&lt;c00000000030be14&gt;] .__kernfs_remove+0x204/0x300
[&lt;c00000000030d428&gt;] .kernfs_remove_by_name_ns+0x68/0xf0
[&lt;c00000000030fb38&gt;] .sysfs_remove_file_ns+0x38/0x60
[&lt;c000000000539354&gt;] .device_remove_attrs+0x54/0xc0
[&lt;c000000000539fd8&gt;] .device_del+0x158/0x250
[&lt;c00000000053a104&gt;] .device_unregister+0x34/0xa0
[&lt;c00000000055bc14&gt;] .unregister_memory_section+0x164/0x170
[&lt;c00000000024ee18&gt;] .__remove_pages+0x108/0x4c0
[&lt;c00000000004b590&gt;] .arch_remove_memory+0x60/0xc0
[&lt;c00000000026446c&gt;] .remove_memory+0x8c/0xe0
[&lt;c00000000007f9f4&gt;] .pseries_remove_memblock+0xd4/0x160
[&lt;c00000000007fcfc&gt;] .pseries_memory_notifier+0x27c/0x290
[&lt;c0000000008ae6cc&gt;] .notifier_call_chain+0x8c/0x100
[&lt;c0000000000d858c&gt;] .__blocking_notifier_call_chain+0x6c/0xe0
[&lt;c00000000071ddec&gt;] .of_property_notify+0x7c/0xc0
[&lt;c00000000071ed3c&gt;] .of_update_property+0x3c/0x1b0
[&lt;c0000000000756cc&gt;] .ofdt_write+0x3dc/0x740
[&lt;c0000000002f60fc&gt;] .proc_reg_write+0xac/0x110
[&lt;c000000000268450&gt;] .vfs_write+0xe0/0x260
[&lt;c000000000269144&gt;] .SyS_write+0x64/0x110
[&lt;c000000000009ffc&gt;] syscall_exit+0x0/0x7c

This patch uses lock_device_hotplug() to protect remove_memory() called
in pseries_remove_memblock(), which is also stated before function
remove_memory():

 * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
 * and online/offline operations before this call, as required by
 * try_offline_node().
 */
void __ref remove_memory(int nid, u64 start, u64 size)

With this lock held, the other process(#1120 above) trying to online the
memory block will retry the system call when calling
lock_device_hotplug_sysfs(), and finally find No such device error.

Signed-off-by: Li Zhong &lt;zhong@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Fix little endian issues in OPAL dump code</title>
<updated>2014-04-28T03:11:24+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-04-22T05:01:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2d6b63bbdd7a649ea17fae19f8bab07d4b292a09'/>
<id>2d6b63bbdd7a649ea17fae19f8bab07d4b292a09</id>
<content type='text'>
Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Create OPAL sglist helper functions and fix endian issues</title>
<updated>2014-04-28T03:11:23+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-04-22T05:01:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3441f04b4b62758a798f9fbbf2047dfedf0329a5'/>
<id>3441f04b4b62758a798f9fbbf2047dfedf0329a5</id>
<content type='text'>
We have two copies of code that creates an OPAL sg list. Consolidate
these into a common set of helpers and fix the endian issues.

The flash interface embedded a version number in the num_entries
field, whereas the dump interface did did not. Since versioning
wasn't added to the flash interface and it is impossible to add
this in a backwards compatible way, just remove it.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We have two copies of code that creates an OPAL sg list. Consolidate
these into a common set of helpers and fix the endian issues.

The flash interface embedded a version number in the num_entries
field, whereas the dump interface did did not. Since versioning
wasn't added to the flash interface and it is impossible to add
this in a backwards compatible way, just remove it.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Fix little endian issues in OPAL error log code</title>
<updated>2014-04-28T03:11:23+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-04-22T05:01:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=14ad0c58d5df6e5911a5413abdc2a9be6a8acb51'/>
<id>14ad0c58d5df6e5911a5413abdc2a9be6a8acb51</id>
<content type='text'>
Fix little endian issues with the OPAL error log code.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Reviewed-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix little endian issues with the OPAL error log code.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Reviewed-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Fix little endian issues with opal_do_notifier calls</title>
<updated>2014-04-28T03:11:22+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-04-22T05:01:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=56b4c993124d15f3b198cc757ba49a0022b5d695'/>
<id>56b4c993124d15f3b198cc757ba49a0022b5d695</id>
<content type='text'>
The bitmap in opal_poll_events and opal_handle_interrupt is
big endian, so we need to byteswap it on little endian builds.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bitmap in opal_poll_events and opal_handle_interrupt is
big endian, so we need to byteswap it on little endian builds.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs</title>
<updated>2014-04-28T03:11:21+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>anton@samba.org</email>
</author>
<published>2014-04-22T05:01:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2bad742388d23c15f2cb355bb992046e30065a11'/>
<id>2bad742388d23c15f2cb355bb992046e30065a11</id>
<content type='text'>
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Reviewed-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.

Signed-off-by: Anton Blanchard &lt;anton@samba.org&gt;
Reviewed-by: Stewart Smith &lt;stewart@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Release the refcount for pci_dev</title>
<updated>2014-04-28T03:11:20+00:00</updated>
<author>
<name>Wei Yang</name>
<email>weiyang@linux.vnet.ibm.com</email>
</author>
<published>2014-04-23T02:26:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4966bfa1b3347ee75e6d93859a2e8ce9a662390c'/>
<id>4966bfa1b3347ee75e6d93859a2e8ce9a662390c</id>
<content type='text'>
On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which
leads to the pci_dev is not destroyed when hotplugging a pci device.

This patch release the unnecessary refcount.

Signed-off-by: Wei Yang &lt;weiyang@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On PowerNV platform, we are holding an unnecessary refcount on a pci_dev, which
leads to the pci_dev is not destroyed when hotplugging a pci device.

This patch release the unnecessary refcount.

Signed-off-by: Wei Yang &lt;weiyang@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>powerpc/powernv: Reduce multi-hit of iommu_add_device()</title>
<updated>2014-04-28T03:11:20+00:00</updated>
<author>
<name>Wei Yang</name>
<email>weiyang@linux.vnet.ibm.com</email>
</author>
<published>2014-04-23T02:26:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3f28c5af3964c11e61e9a58df77cae5ebdb8209e'/>
<id>3f28c5af3964c11e61e9a58df77cae5ebdb8209e</id>
<content type='text'>
During the EEH hotplug event, iommu_add_device() will be invoked three times
and two of them will trigger warning or error.

The three times to invoke the iommu_add_device() are:

    pci_device_add
       ...
       set_iommu_table_base_and_group   &lt;- 1st time, fail
    device_add
       ...
       tce_iommu_bus_notifier           &lt;- 2nd time, succees
    pcibios_add_pci_devices
       ...
       pcibios_setup_bus_devices        &lt;- 3rd time, re-attach

The first time fails, since the dev-&gt;kobj-&gt;sd is not initialized. The
dev-&gt;kobj-&gt;sd is initialized in device_add().
The third time's warning is triggered by the re-attach of the iommu_group.

After applying this patch, the error

    iommu_tce: 0003:05:00.0 has not been added, ret=-14

and the warning

    [  204.123609] ------------[ cut here ]------------
    [  204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125
    [  204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt
    [  204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102
    [  204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000
    [  204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0
    [  204.124506] REGS: c0000027ed50f440 TRAP: 0700   Not tainted  (3.14.0-rc5yw+)
    [  204.124558] MSR: 9000000000029032 &lt;SF,HV,EE,ME,IR,DR,RI&gt;  CR: 88008084  XER: 20000000
    [  204.124682] CFAR: c00000000006c644 SOFTE: 1
    GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300
    GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110
    GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062
    GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80
    GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
    GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800
    GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000
    [  204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0
    [  204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
    [  204.125443] Call Trace:
    [  204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable)
    [  204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
    [  204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340
    [  204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0
    [  204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0
    [  204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0
    [  204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0
    [  204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480
    [  204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340
    [  204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0
    [  204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130
    [  204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c
    [  204.126556] Instruction dump:
    [  204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000
    [  204.126787] 60000000 e87e0298 3143ffff 7d2a1910 &lt;0b090000&gt; 2fa90000 40de00c8 ebfe0218
    [  204.126966] ---[ end trace 6e7aefd80add2973 ]---

are cleared.

This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which
revert part of the change in commit d905c5df(PPC: POWERNV: move
iommu_add_device earlier).

Signed-off-by: Wei Yang &lt;weiyang@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During the EEH hotplug event, iommu_add_device() will be invoked three times
and two of them will trigger warning or error.

The three times to invoke the iommu_add_device() are:

    pci_device_add
       ...
       set_iommu_table_base_and_group   &lt;- 1st time, fail
    device_add
       ...
       tce_iommu_bus_notifier           &lt;- 2nd time, succees
    pcibios_add_pci_devices
       ...
       pcibios_setup_bus_devices        &lt;- 3rd time, re-attach

The first time fails, since the dev-&gt;kobj-&gt;sd is not initialized. The
dev-&gt;kobj-&gt;sd is initialized in device_add().
The third time's warning is triggered by the re-attach of the iommu_group.

After applying this patch, the error

    iommu_tce: 0003:05:00.0 has not been added, ret=-14

and the warning

    [  204.123609] ------------[ cut here ]------------
    [  204.123645] WARNING: at arch/powerpc/kernel/iommu.c:1125
    [  204.123680] Modules linked in: xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT bnep bluetooth 6lowpan_iphc rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc mlx4_ib ib_sa ib_mad ib_core ib_addr ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw bnx2x tg3 mlx4_core nfsd ptp mdio ses libcrc32c nfs_acl enclosure be2net pps_core shpchp lockd kvm uinput sunrpc binfmt_misc lpfc scsi_transport_fc ipr scsi_tgt
    [  204.124356] CPU: 18 PID: 650 Comm: eehd Not tainted 3.14.0-rc5yw+ #102
    [  204.124400] task: c0000027ed485670 ti: c0000027ed50c000 task.ti: c0000027ed50c000
    [  204.124453] NIP: c00000000003cf80 LR: c00000000006c648 CTR: c00000000006c5c0
    [  204.124506] REGS: c0000027ed50f440 TRAP: 0700   Not tainted  (3.14.0-rc5yw+)
    [  204.124558] MSR: 9000000000029032 &lt;SF,HV,EE,ME,IR,DR,RI&gt;  CR: 88008084  XER: 20000000
    [  204.124682] CFAR: c00000000006c644 SOFTE: 1
    GPR00: c00000000006c648 c0000027ed50f6c0 c000000001398380 c0000027ec260300
    GPR04: c0000027ea92c000 c00000000006ad00 c0000000016e41b0 0000000000000110
    GPR08: c0000000012cd4c0 0000000000000001 c0000027ec2602ff 0000000000000062
    GPR12: 0000000028008084 c00000000fdca200 c0000000000d1d90 c0000027ec281a80
    GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
    GPR24: 000000005342697b 0000000000002906 c000001fe6ac9800 c000001fe6ac9800
    GPR28: 0000000000000000 c0000000016e3a80 c0000027ea92c090 c0000027ea92c000
    [  204.125353] NIP [c00000000003cf80] .iommu_add_device+0x30/0x1f0
    [  204.125399] LR [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
    [  204.125443] Call Trace:
    [  204.125464] [c0000027ed50f6c0] [c0000027ed50f750] 0xc0000027ed50f750 (unreliable)
    [  204.125526] [c0000027ed50f750] [c00000000006c648] .pnv_pci_ioda_dma_dev_setup+0x88/0xb0
    [  204.125588] [c0000027ed50f7d0] [c000000000069cc8] .pnv_pci_dma_dev_setup+0x78/0x340
    [  204.125650] [c0000027ed50f870] [c000000000044408] .pcibios_setup_device+0x88/0x2f0
    [  204.125712] [c0000027ed50f940] [c000000000046040] .pcibios_setup_bus_devices+0x60/0xd0
    [  204.125774] [c0000027ed50f9c0] [c000000000043acc] .pcibios_add_pci_devices+0xdc/0x1c0
    [  204.125837] [c0000027ed50fa50] [c00000000086f970] .eeh_reset_device+0x36c/0x4f0
    [  204.125939] [c0000027ed50fb20] [c00000000003a2d8] .eeh_handle_normal_event+0x448/0x480
    [  204.126068] [c0000027ed50fbc0] [c00000000003a35c] .eeh_handle_event+0x4c/0x340
    [  204.126192] [c0000027ed50fc80] [c00000000003a74c] .eeh_event_handler+0xfc/0x1b0
    [  204.126319] [c0000027ed50fd30] [c0000000000d1ea0] .kthread+0x110/0x130
    [  204.126430] [c0000027ed50fe30] [c00000000000a460] .ret_from_kernel_thread+0x5c/0x7c
    [  204.126556] Instruction dump:
    [  204.126610] 7c0802a6 fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ff71 7c7e1b78 60000000
    [  204.126787] 60000000 e87e0298 3143ffff 7d2a1910 &lt;0b090000&gt; 2fa90000 40de00c8 ebfe0218
    [  204.126966] ---[ end trace 6e7aefd80add2973 ]---

are cleared.

This patch removes iommu_add_device() in pnv_pci_ioda_dma_dev_setup(), which
revert part of the change in commit d905c5df(PPC: POWERNV: move
iommu_add_device earlier).

Signed-off-by: Wei Yang &lt;weiyang@linux.vnet.ibm.com&gt;
Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
