Commit c77a6544 authored by Greg Kroah-Hartman's avatar Greg Kroah-Hartman
Browse files

Merge tag 'thunderbolt-for-v6.19-rc1' of... 

Merge tag 'thunderbolt-for-v6.19-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-nextx

Mika writes:

thunderbolt: Changes for v6.19 merge window

This includes following USB4/Thunderbolt changes for the v6.19 merge
window:

  - Documentation fixes
  - Fixes for various typos found in the driver
  - Replace use of system_wq with system_percpu_wq.

All these have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v6.19-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Fix typos in xdomain.c
  thunderbolt: Fix typos in usb4.c
  thunderbolt: Fix typos in tunnel.c
  thunderbolt: Fix typos in tmu.c
  thunderbolt: Fix typos in tb_regs.h
  thunderbolt: Fix typos in tb.h
  thunderbolt: Fix typos in tb.c
  thunderbolt: Fix typos in switch.c
  thunderbolt: Fix typos in retimer.c
  thunderbolt: Fix typos in nhi.c
  thunderbolt: Fix typos in lc.c
  thunderbolt: Fix typos in icm.c
  thunderbolt: Fix typos in domain.c
  thunderbolt: Fix typos in debugfs.c
  thunderbolt: Fix typos in ctl.c
  thunderbolt: Replace use of system_wq with system_percpu_wq
  thunderbolt: Update deprecated firmware update site in icm.c
  thunderbolt: Update NVM firmware upgrade documentation
  thunderbolt: Fix typo in tb_eeprom_ctl_read documentation
parents 955a48a5 479d186f

Documentation/admin-guide/thunderbolt.rst

+35 −15
Original line number Diff line number Diff line
@@ -203,10 +203,10 @@ host controller or a device, it is important that the firmware can be 
upgraded to the latest where possible bugs in it have been fixed.

Typically OEMs provide this firmware from their support site.



There is also a central site which has links where to download firmware

for some machines:



  `Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_

Currently, recommended method of updating firmware is through "fwupd" tool.

It uses LVFS (Linux Vendor Firmware Service) portal by default to get the

latest firmware from hardware vendors and updates connected devices if found

compatible. For details refer to: https://github.com/fwupd/fwupd.



Before you upgrade firmware on a device, host or retimer, please make

sure it is a suitable upgrade. Failing to do that may render the device
@@ -215,18 +215,40 @@ tools! 


Host NVM upgrade on Apple Macs is not supported.



Once the NVM image has been downloaded, you need to plug in a

Thunderbolt device so that the host controller appears. It does not

matter which device is connected (unless you are upgrading NVM on a

device - then you need to connect that particular device).

Fwupd is installed by default. If you don't have it on your system, simply

use your distro package manager to get it.



To see possible updates through fwupd, you need to plug in a Thunderbolt

device so that the host controller appears. It does not matter which

device is connected (unless you are upgrading NVM on a device - then you

need to connect that particular device).



Note an OEM-specific method to power the controller up ("force power") may

be available for your system in which case there is no need to plug in a

Thunderbolt device.



After that we can write the firmware to the non-active parts of the NVM

of the host or device. As an example here is how Intel NUC6i7KYK (Skull

Canyon) Thunderbolt controller NVM is upgraded::

Updating firmware using fwupd is straightforward - refer to official

readme on fwupd github.



If firmware image is written successfully, the device shortly disappears.

Once it comes back, the driver notices it and initiates a full power

cycle. After a while device appears again and this time it should be

fully functional.



Device of interest should display new version under "Current version"

and "Update State: Success" in fwupd's interface.



Upgrading firmware manually

---------------------------------------------------------------

If possible, use fwupd to updated the firmware. However, if your device OEM

has not uploaded the firmware to LVFS, but it is available for download

from their side, you can use method below to directly upgrade the

firmware.



Manual firmware update can be done with 'dd' tool. To update firmware

using this method, you need to write it to the non-active parts of NVM

of the host or device. Example on how to update Intel NUC6i7KYK

(Skull Canyon) Thunderbolt controller NVM::



  # dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem
@@ -235,10 +257,8 @@ upgrade process as follows:: 


  # echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate



If no errors are returned, the host controller shortly disappears. Once

it comes back the driver notices it and initiates a full power cycle.

After a while the host controller appears again and this time it should

be fully functional.

If no errors are returned, device should behave as described in previous

section.



We can verify that the new NVM firmware is active by running the following

commands::

drivers/thunderbolt/ctl.c

+1 −1
Original line number Diff line number Diff line
@@ -412,7 +412,7 @@ static void tb_ctl_rx_submit(struct ctl_pkg *pkg) 
					     * We ignore failures during stop.

					     * All rx packets are referenced

					     * from ctl->rx_packets, so we do

					     * not loose them.

					     * not lose them.

					     */

}

drivers/thunderbolt/debugfs.c

+2 −2
Original line number Diff line number Diff line
@@ -201,7 +201,7 @@ static bool parse_line(char **line, u32 *offs, u32 *val, int short_fmt_len, 
#if IS_ENABLED(CONFIG_USB4_DEBUGFS_WRITE)

/*

 * Path registers need to be written in double word pairs and they both must be

 * read before written. This writes one double word in patch config space

 * read before written. This writes one double word in path config space

 * following the spec flow.

 */

static int path_write_one(struct tb_port *port, u32 val, u32 offset)
@@ -1196,7 +1196,7 @@ static int validate_margining(struct tb_margining *margining) 
{

	/*

	 * For running on RX2 the link must be asymmetric with 3

	 * receivers. Because this is can change dynamically, check it

	 * receivers. Because this can change dynamically, check it

	 * here before we start the margining and report back error if

	 * expectations are not met.

	 */

drivers/thunderbolt/domain.c

+1 −1
Original line number Diff line number Diff line
@@ -376,7 +376,7 @@ struct tb *tb_domain_alloc(struct tb_nhi *nhi, int timeout_msec, size_t privsize 
	struct tb *tb;



	/*

	 * Make sure the structure sizes map with that the hardware

	 * Make sure the structure sizes map with what the hardware

	 * expects because bit-fields are being used.

	 */

	BUILD_BUG_ON(sizeof(struct tb_regs_switch_header) != 5 * 4);

drivers/thunderbolt/eeprom.c

+1 −1
Original line number Diff line number Diff line
@@ -21,7 +21,7 @@ static int tb_eeprom_ctl_write(struct tb_switch *sw, struct tb_eeprom_ctl *ctl) 
}



/*

 * tb_eeprom_ctl_write() - read control word

 * tb_eeprom_ctl_read() - read control word

 */

static int tb_eeprom_ctl_read(struct tb_switch *sw, struct tb_eeprom_ctl *ctl)

{