From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Darren Hart <dvhart@infradead.org>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>,
Mario Limonciello <mario.limonciello@dell.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Yehezkel Bernat <yehezkel.bernat@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Amir Levy <amir.jer.levy@intel.com>,
Michael Jamet <michael.jamet@intel.com>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree
Date: Mon, 13 Nov 2017 16:28:20 +1100 [thread overview]
Message-ID: <20171113162810.28dd7f87@canb.auug.org.au> (raw)
In-Reply-To: <20171009175633.dm7hjmgoxusspue5@sirena.co.uk>
Hi all,
On Mon, 9 Oct 2017 18:56:33 +0100 Mark Brown <broonie@kernel.org> 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
next prev parent reply other threads:[~2017-11-13 5:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-09 17:56 linux-next: manual merge of the drivers-x86 tree with the net-next tree Mark Brown
2017-10-09 19:43 ` Mika Westerberg
2017-10-09 19:56 ` Mark Brown
2017-10-09 23:18 ` Darren Hart
2017-10-10 11:49 ` Mika Westerberg
2017-11-13 5:28 ` Stephen Rothwell [this message]
2017-11-08 3:29 Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171113162810.28dd7f87@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=amir.jer.levy@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=davem@davemloft.net \
--cc=dvhart@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mario.limonciello@dell.com \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=yehezkel.bernat@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).