Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

From: Stephen Rothwell
Date: Mon Nov 13 2017 - 00:28:28 EST


Hi all,

On Mon, 9 Oct 2017 18:56:33 +0100 Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> Documentation/admin-guide/thunderbolt.rst
>
> between commit:
>
> e69b6c02b4c3b ("net: Add support for networking over Thunderbolt cable")
>
> from the net-next tree and commit:
>
> ce6a90027c10f ("platform/x86: Add driver to force WMI Thunderbolt controller power status")
>
> from the drivers-x86 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc Documentation/admin-guide/thunderbolt.rst
> index 5c62d11d77e8,dadcd66ee12f..000000000000
> --- a/Documentation/admin-guide/thunderbolt.rst
> +++ b/Documentation/admin-guide/thunderbolt.rst
> @@@ -198,26 -198,17 +198,41 @@@ information is missing
> To recover from this mode, one needs to flash a valid NVM image to the
> host host controller in the same way it is done in the previous chapter.
>
> +Networking over Thunderbolt cable
> +---------------------------------
> +Thunderbolt technology allows software communication across two hosts
> +connected by a Thunderbolt cable.
> +
> +It is possible to tunnel any kind of traffic over Thunderbolt link but
> +currently we only support Apple ThunderboltIP protocol.
> +
> +If the other host is running Windows or macOS only thing you need to
> +do is to connect Thunderbolt cable between the two hosts, the
> +``thunderbolt-net`` is loaded automatically. If the other host is also
> +Linux you should load ``thunderbolt-net`` manually on one host (it does
> +not matter which one)::
> +
> + # modprobe thunderbolt-net
> +
> +This triggers module load on the other host automatically. If the driver
> +is built-in to the kernel image, there is no need to do anything.
> +
> +The driver will create one virtual ethernet interface per Thunderbolt
> +port which are named like ``thunderbolt0`` and so on. From this point
> +you can either use standard userspace tools like ``ifconfig`` to
> +configure the interface or let your GUI to handle it automatically.
> ++
> + Forcing power
> + -------------
> + Many OEMs include a method that can be used to force the power of a
> + thunderbolt controller to an "On" state even if nothing is connected.
> + If supported by your machine this will be exposed by the WMI bus with
> + a sysfs attribute called "force_power".
> +
> + For example the intel-wmi-thunderbolt driver exposes this attribute in:
> + /sys/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
> +
> + To force the power to on, write 1 to this attribute file.
> + To disable force power, write 0 to this attribute file.
> +
> + Note: it's currently not possible to query the force power state of a platform.

Just a reminder that this conflict still exists.

--
Cheers,
Stephen Rothwell