<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt-budgetable-locks.git/.git/drivers/thunderbolt, branch update_litmus_2019</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/'/>
<entry>
<title>thunderbolt: Drop unnecessary read when writing LC command in Ice Lake</title>
<updated>2019-10-08T09:08:21+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-09-16T14:03:03+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=747125db6dcd8bcc21f13d013f6e6a2acade21ee'/>
<id>747125db6dcd8bcc21f13d013f6e6a2acade21ee</id>
<content type='text'>
The read is not needed as we overwrite the returned value in the next
line anyway so drop it.

Fixes: 3cdb9446a117 ("thunderbolt: Add support for Intel Ice Lake")
Reported-by: Nicholas Johnson &lt;nicholas.johnson-opensource@outlook.com.au&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The read is not needed as we overwrite the returned value in the next
line anyway so drop it.

Fixes: 3cdb9446a117 ("thunderbolt: Add support for Intel Ice Lake")
Reported-by: Nicholas Johnson &lt;nicholas.johnson-opensource@outlook.com.au&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Fix lockdep circular locking depedency warning</title>
<updated>2019-10-08T09:08:21+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-09-19T12:28:58+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=6f6709734274aef75058356e029d5e8f86d0d53b'/>
<id>6f6709734274aef75058356e029d5e8f86d0d53b</id>
<content type='text'>
When lockdep is enabled, plugging Thunderbolt dock on Dominik's laptop
triggers following splat:

  ======================================================
  WARNING: possible circular locking dependency detected
  5.3.0-rc6+ #1 Tainted: G                T
  ------------------------------------------------------
  pool-/usr/lib/b/1258 is trying to acquire lock:
  000000005ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210

  but task is already holding lock:
  00000000bfb796b5 (&amp;tb-&gt;lock){+.+.}, at: authorized_store+0x7c/0x210

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -&gt; #1 (&amp;tb-&gt;lock){+.+.}:
         __mutex_lock+0xac/0x9a0
         tb_domain_add+0x2d/0x130
         nhi_probe+0x1dd/0x330
         pci_device_probe+0xd2/0x150
         really_probe+0xee/0x280
         driver_probe_device+0x50/0xc0
         bus_for_each_drv+0x84/0xd0
         __device_attach+0xe4/0x150
         pci_bus_add_device+0x4e/0x70
         pci_bus_add_devices+0x2e/0x66
         pci_bus_add_devices+0x59/0x66
         pci_bus_add_devices+0x59/0x66
         enable_slot+0x344/0x450
         acpiphp_check_bridge.part.0+0x119/0x150
         acpiphp_hotplug_notify+0xaa/0x140
         acpi_device_hotplug+0xa2/0x3f0
         acpi_hotplug_work_fn+0x1a/0x30
         process_one_work+0x234/0x580
         worker_thread+0x50/0x3b0
         kthread+0x10a/0x140
         ret_from_fork+0x3a/0x50

  -&gt; #0 (pci_rescan_remove_lock){+.+.}:
         __lock_acquire+0xe54/0x1ac0
         lock_acquire+0xb8/0x1b0
         __mutex_lock+0xac/0x9a0
         authorized_store+0xe8/0x210
         kernfs_fop_write+0x125/0x1b0
         vfs_write+0xc2/0x1d0
         ksys_write+0x6c/0xf0
         do_syscall_64+0x50/0x180
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0                    CPU1
         ----                    ----
    lock(&amp;tb-&gt;lock);
                                 lock(pci_rescan_remove_lock);
                                 lock(&amp;tb-&gt;lock);
    lock(pci_rescan_remove_lock);

   *** DEADLOCK ***
  5 locks held by pool-/usr/lib/b/1258:
   #0: 000000003df1a1ad (&amp;f-&gt;f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
   #1: 0000000095a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0
   #2: 0000000017a7d714 (&amp;of-&gt;mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0
   #3: 000000004f262981 (kn-&gt;count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0
   #4: 00000000bfb796b5 (&amp;tb-&gt;lock){+.+.}, at: authorized_store+0x7c/0x210

  stack backtrace:
  CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: G                T 5.3.0-rc6+ #1

On an system using ACPI hotplug the host router gets hotplugged first and then
the firmware starts sending notifications about connected devices so the above
scenario should not happen in reality. However, after taking a second
look at commit a03e828915c0 ("thunderbolt: Serialize PCIe tunnel
creation with PCI rescan") that introduced the locking, I don't think it
is actually correct. It may have cured the symptom but probably the real
root cause was somewhere closer to PCI stack and possibly is already
fixed with recent kernels. I also tried to reproduce the original issue
with the commit reverted but could not.

So to keep lockdep happy and the code bit less complex drop calls to
pci_lock_rescan_remove()/pci_unlock_rescan_remove() in
tb_switch_set_authorized() effectively reverting a03e828915c0.

Link: https://lkml.org/lkml/2019/8/30/513
Fixes: a03e828915c0 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan")
Reported-by: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When lockdep is enabled, plugging Thunderbolt dock on Dominik's laptop
triggers following splat:

  ======================================================
  WARNING: possible circular locking dependency detected
  5.3.0-rc6+ #1 Tainted: G                T
  ------------------------------------------------------
  pool-/usr/lib/b/1258 is trying to acquire lock:
  000000005ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210

  but task is already holding lock:
  00000000bfb796b5 (&amp;tb-&gt;lock){+.+.}, at: authorized_store+0x7c/0x210

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -&gt; #1 (&amp;tb-&gt;lock){+.+.}:
         __mutex_lock+0xac/0x9a0
         tb_domain_add+0x2d/0x130
         nhi_probe+0x1dd/0x330
         pci_device_probe+0xd2/0x150
         really_probe+0xee/0x280
         driver_probe_device+0x50/0xc0
         bus_for_each_drv+0x84/0xd0
         __device_attach+0xe4/0x150
         pci_bus_add_device+0x4e/0x70
         pci_bus_add_devices+0x2e/0x66
         pci_bus_add_devices+0x59/0x66
         pci_bus_add_devices+0x59/0x66
         enable_slot+0x344/0x450
         acpiphp_check_bridge.part.0+0x119/0x150
         acpiphp_hotplug_notify+0xaa/0x140
         acpi_device_hotplug+0xa2/0x3f0
         acpi_hotplug_work_fn+0x1a/0x30
         process_one_work+0x234/0x580
         worker_thread+0x50/0x3b0
         kthread+0x10a/0x140
         ret_from_fork+0x3a/0x50

  -&gt; #0 (pci_rescan_remove_lock){+.+.}:
         __lock_acquire+0xe54/0x1ac0
         lock_acquire+0xb8/0x1b0
         __mutex_lock+0xac/0x9a0
         authorized_store+0xe8/0x210
         kernfs_fop_write+0x125/0x1b0
         vfs_write+0xc2/0x1d0
         ksys_write+0x6c/0xf0
         do_syscall_64+0x50/0x180
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0                    CPU1
         ----                    ----
    lock(&amp;tb-&gt;lock);
                                 lock(pci_rescan_remove_lock);
                                 lock(&amp;tb-&gt;lock);
    lock(pci_rescan_remove_lock);

   *** DEADLOCK ***
  5 locks held by pool-/usr/lib/b/1258:
   #0: 000000003df1a1ad (&amp;f-&gt;f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
   #1: 0000000095a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0
   #2: 0000000017a7d714 (&amp;of-&gt;mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0
   #3: 000000004f262981 (kn-&gt;count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0
   #4: 00000000bfb796b5 (&amp;tb-&gt;lock){+.+.}, at: authorized_store+0x7c/0x210

  stack backtrace:
  CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: G                T 5.3.0-rc6+ #1

On an system using ACPI hotplug the host router gets hotplugged first and then
the firmware starts sending notifications about connected devices so the above
scenario should not happen in reality. However, after taking a second
look at commit a03e828915c0 ("thunderbolt: Serialize PCIe tunnel
creation with PCI rescan") that introduced the locking, I don't think it
is actually correct. It may have cured the symptom but probably the real
root cause was somewhere closer to PCI stack and possibly is already
fixed with recent kernels. I also tried to reproduce the original issue
with the commit reverted but could not.

So to keep lockdep happy and the code bit less complex drop calls to
pci_lock_rescan_remove()/pci_unlock_rescan_remove() in
tb_switch_set_authorized() effectively reverting a03e828915c0.

Link: https://lkml.org/lkml/2019/8/30/513
Fixes: a03e828915c0 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan")
Reported-by: Dominik Brodowski &lt;linux@dominikbrodowski.net&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Read DP IN adapter first two dwords in one go</title>
<updated>2019-10-08T09:08:01+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-09-19T11:55:23+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=fd5c46b754d4799afda8dcdd6851e0390aa4961a'/>
<id>fd5c46b754d4799afda8dcdd6851e0390aa4961a</id>
<content type='text'>
When we discover existing DP tunnels the code checks whether DP IN
adapter port is enabled by calling tb_dp_port_is_enabled() before it
continues the discovery process. On Light Ridge (gen 1) controller
reading only the first dword of the DP IN config space causes subsequent
access to the same DP IN port path config space to fail or return
invalid data as can be seen in the below splat:

  thunderbolt 0000:07:00.0: CFG_ERROR(0:d): Invalid config space or offset
  Call Trace:
   tb_cfg_read+0xb9/0xd0
   __tb_path_deactivate_hop+0x98/0x210
   tb_path_activate+0x228/0x7d0
   tb_tunnel_restart+0x95/0x200
   tb_handle_hotplug+0x30e/0x630
   process_one_work+0x1b4/0x340
   worker_thread+0x44/0x3d0
   kthread+0xeb/0x120
   ? process_one_work+0x340/0x340
   ? kthread_park+0xa0/0xa0
   ret_from_fork+0x1f/0x30

If both DP In adapter config dwords are read in one go the issue does
not reproduce. This is likely firmware bug but we can work it around by
always reading the two dwords in one go. There should be no harm for
other controllers either so can do it unconditionally.

Link: https://lkml.org/lkml/2019/8/28/160
Reported-by: Brad Campbell &lt;lists2009@fnarfbargle.com&gt;
Tested-by: Brad Campbell &lt;lists2009@fnarfbargle.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we discover existing DP tunnels the code checks whether DP IN
adapter port is enabled by calling tb_dp_port_is_enabled() before it
continues the discovery process. On Light Ridge (gen 1) controller
reading only the first dword of the DP IN config space causes subsequent
access to the same DP IN port path config space to fail or return
invalid data as can be seen in the below splat:

  thunderbolt 0000:07:00.0: CFG_ERROR(0:d): Invalid config space or offset
  Call Trace:
   tb_cfg_read+0xb9/0xd0
   __tb_path_deactivate_hop+0x98/0x210
   tb_path_activate+0x228/0x7d0
   tb_tunnel_restart+0x95/0x200
   tb_handle_hotplug+0x30e/0x630
   process_one_work+0x1b4/0x340
   worker_thread+0x44/0x3d0
   kthread+0xeb/0x120
   ? process_one_work+0x340/0x340
   ? kthread_park+0xa0/0xa0
   ret_from_fork+0x1f/0x30

If both DP In adapter config dwords are read in one go the issue does
not reproduce. This is likely firmware bug but we can work it around by
always reading the two dwords in one go. There should be no harm for
other controllers either so can do it unconditionally.

Link: https://lkml.org/lkml/2019/8/28/160
Reported-by: Brad Campbell &lt;lists2009@fnarfbargle.com&gt;
Tested-by: Brad Campbell &lt;lists2009@fnarfbargle.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Add support for Intel Ice Lake</title>
<updated>2019-08-26T09:15:06+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-01-16T20:19:00+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=3cdb9446a117d5d63af823bde6fe6babc312e77b'/>
<id>3cdb9446a117d5d63af823bde6fe6babc312e77b</id>
<content type='text'>
The Thunderbolt controller is integrated into the Ice Lake CPU itself
and requires special flows to power it on and off using force power bit
in NHI VSEC registers. Runtime PM (RTD3) and Sx flows also differ from
the discrete solutions. Now the firmware notifies the driver whether
RTD3 entry or exit are possible. The driver is responsible of sending
Go2Sx command through link controller mailbox when system enters Sx
states (suspend-to-mem/disk). Rest of the ICM firwmare flows follow
Titan Ridge.

Signed-off-by: Raanan Avargil &lt;raanan.avargil@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Thunderbolt controller is integrated into the Ice Lake CPU itself
and requires special flows to power it on and off using force power bit
in NHI VSEC registers. Runtime PM (RTD3) and Sx flows also differ from
the discrete solutions. Now the firmware notifies the driver whether
RTD3 entry or exit are possible. The driver is responsible of sending
Go2Sx command through link controller mailbox when system enters Sx
states (suspend-to-mem/disk). Rest of the ICM firwmare flows follow
Titan Ridge.

Signed-off-by: Raanan Avargil &lt;raanan.avargil@intel.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Expose active parts of NVM even if upgrade is not supported</title>
<updated>2019-08-26T09:15:01+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-02-05T09:51:40+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=3f415e5ee18b0097755afc3ac3a5640b196a239e'/>
<id>3f415e5ee18b0097755afc3ac3a5640b196a239e</id>
<content type='text'>
Ice Lake Thunderbolt controller NVM firmware is part of the BIOS image
which means it is not writable through the DMA port anymore. However, we
can still read it so we can keep nvm_version and active parts of NVM.
This way users still can find out the active NVM version and other
potentially useful information directly from Linux.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Ice Lake Thunderbolt controller NVM firmware is part of the BIOS image
which means it is not writable through the DMA port anymore. However, we
can still read it so we can keep nvm_version and active parts of NVM.
This way users still can find out the active NVM version and other
potentially useful information directly from Linux.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Hide switch attributes that are not set</title>
<updated>2019-08-26T09:14:56+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-09-11T12:34:23+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=58f414fa435cf728a82f435bac4781da86afb623'/>
<id>58f414fa435cf728a82f435bac4781da86afb623</id>
<content type='text'>
Thunderbolt host routers may not always contain DROM that includes
device identification information. This is mostly needed for Ice Lake
systems but some Falcon Ridge controllers on PCs also do not have DROM.

In that case hide the identification attributes.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Thunderbolt host routers may not always contain DROM that includes
device identification information. This is mostly needed for Ice Lake
systems but some Falcon Ridge controllers on PCs also do not have DROM.

In that case hide the identification attributes.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Do not fail adding switch if some port is not implemented</title>
<updated>2019-08-26T09:14:51+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-07-04T05:50:01+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=d94dcbb10183f3b384c84e65724d2b753aa53c4d'/>
<id>d94dcbb10183f3b384c84e65724d2b753aa53c4d</id>
<content type='text'>
There are two ways to mark a port as unimplemented. Typical way is to
return port type as TB_TYPE_INACTIVE when its config space is read.
Alternatively if the port is not physically present (such as ports 10
and 11 in ICL) reading from port config space returns
TB_CFG_ERROR_INVALID_CONFIG_SPACE instead. Currently the driver bails
out from adding the switch if it receives any error during port
inititialization which is wrong.

Handle this properly and just leave the port as TB_TYPE_INACTIVE before
continuing to the next port.

This also allows us to get rid of special casing for Light Ridge port 5
in eeprom.c.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are two ways to mark a port as unimplemented. Typical way is to
return port type as TB_TYPE_INACTIVE when its config space is read.
Alternatively if the port is not physically present (such as ports 10
and 11 in ICL) reading from port config space returns
TB_CFG_ERROR_INVALID_CONFIG_SPACE instead. Currently the driver bails
out from adding the switch if it receives any error during port
inititialization which is wrong.

Handle this properly and just leave the port as TB_TYPE_INACTIVE before
continuing to the next port.

This also allows us to get rid of special casing for Light Ridge port 5
in eeprom.c.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Use 32-bit writes when writing ring producer/consumer</title>
<updated>2019-08-26T09:14:46+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-07-04T05:46:07+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=943795219d3cb9f8ce6ce51cad3ffe1f61e95c6b'/>
<id>943795219d3cb9f8ce6ce51cad3ffe1f61e95c6b</id>
<content type='text'>
The register access should be using 32-bit reads/writes according to the
datasheet. With the previous generation hardware 16-bit writes have been
working but starting with ICL this is not the case anymore so fix
producer/consumer register update to use correct width register address.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The register access should be using 32-bit reads/writes according to the
datasheet. With the previous generation hardware 16-bit writes have been
working but starting with ICL this is not the case anymore so fix
producer/consumer register update to use correct width register address.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Move NVM upgrade support flag to struct icm</title>
<updated>2019-08-26T09:14:32+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2018-01-16T20:30:40+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=f437c24bf694b0293f835dea8c25e3a5c1433d07'/>
<id>f437c24bf694b0293f835dea8c25e3a5c1433d07</id>
<content type='text'>
This is depends on the controller and on the platform/CPU we are
running. Move it to struct icm so we can set it per controller.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is depends on the controller and on the platform/CPU we are
running. Move it to struct icm so we can set it per controller.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
Tested-by: Mario Limonciello &lt;mario.limonciello@dell.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Correct path indices for PCIe tunnel</title>
<updated>2019-08-26T09:08:57+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2019-06-11T16:31:26+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-budgetable-locks.git/.git/commit/?id=ce19f91eae43e39d5a1da55344756ab5a3c7e8d1'/>
<id>ce19f91eae43e39d5a1da55344756ab5a3c7e8d1</id>
<content type='text'>
PCIe tunnel path indices got mixed up when we added support for tunnels
between switches that are not adjacent. This did not affect the
functionality as it is just an index but fix it now nevertheless to make
the code easier to understand.

Reported-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Fixes: 8c7acaaf020f ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches")
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PCIe tunnel path indices got mixed up when we added support for tunnels
between switches that are not adjacent. This did not affect the
functionality as it is just an index but fix it now nevertheless to make
the code easier to understand.

Reported-by: Rajmohan Mani &lt;rajmohan.mani@intel.com&gt;
Fixes: 8c7acaaf020f ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches")
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Yehezkel Bernat &lt;YehezkelShB@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
