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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

Hi Darren,

[Apologies for multiple copies - for some reason vger seems to eat mails
I send from scripts, still trying to figure this out]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mika Westerberg]

On Mon, Oct 09, 2017 at 06:56:33PM +0100, Mark Brown wrote:
>  +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.

If possible, I would rather move this chapter to be before "Networking
over Thunderbolt cable". Reason is that it then follows NVM flashing
chapter which is typically where you need to force power in the first
place.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Mon, Oct 09, 2017 at 10:43:01PM +0300, Mika Westerberg wrote:

> If possible, I would rather move this chapter to be before "Networking
> over Thunderbolt cable". Reason is that it then follows NVM flashing
> chapter which is typically where you need to force power in the first
> place.

I guess that's something best sorted out either in the relevant trees or
during the merge window?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Darren Hart]

On Mon, Oct 09, 2017 at 08:56:34PM +0100, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 10:43:01PM +0300, Mika Westerberg wrote:
> 
> > If possible, I would rather move this chapter to be before "Networking
> > over Thunderbolt cable". Reason is that it then follows NVM flashing
> > chapter which is typically where you need to force power in the first
> > place.
> 

Agreed.

> I guess that's something best sorted out either in the relevant trees or
> during the merge window?

I'm not sure how we would deal with it in the trees. Best to note this during
the merge window - whichever goes in second. Test merge will identify the merge
conflict, and we can include a note to Linus on the preference.

-- 
Darren Hart
VMware Open Source Technology Center

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

[Mika Westerberg]

On Mon, Oct 09, 2017 at 04:18:10PM -0700, Darren Hart wrote:

> I'm not sure how we would deal with it in the trees. Best to note this during
> the merge window - whichever goes in second. Test merge will identify the merge
> conflict, and we can include a note to Linus on the preference.

That sounds good, thanks!

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

[Stephen Rothwell]

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

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

[Stephen Rothwell]

Hi Darren,

Today's linux-next merge of the drivers-x86 tree got a conflict in:

  tools/Makefile

between commit:

  a92bb546cff0 ("tools: rename tools/net directory to tools/bpf")

from the net-next tree and commit:

  9d64fc08f6fe ("tools/wmi: add a sample for dell smbios communication over WMI")

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.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/Makefile
index c03b4f69d5b7,9d2fd2606810..000000000000
--- a/tools/Makefile
+++ b/tools/Makefile
@@@ -58,7 -58,7 +59,7 @@@ acpi: FORC
  cpupower: FORCE
  	$(call descend,power/$@)
  
- cgroup firewire hv guest spi usb virtio vm bpf iio gpio objtool leds: FORCE
 -cgroup firewire hv guest spi usb virtio vm net iio gpio objtool leds wmi: FORCE
++cgroup firewire hv guest spi usb virtio vm bpf iio gpio objtool leds wmi: FORCE
  	$(call descend,$@)
  
  liblockdep: FORCE
@@@ -92,8 -92,8 +93,8 @@@ kvm_stat: FORC
  
  all: acpi cgroup cpupower gpio hv firewire liblockdep \
  		perf selftests spi turbostat usb \
 -		virtio vm net x86_energy_perf_policy \
 +		virtio vm bpf x86_energy_perf_policy \
- 		tmon freefall iio objtool kvm_stat
+ 		tmon freefall iio objtool kvm_stat wmi
  
  acpi_install:
  	$(call descend,power/$(@:_install=),install)
@@@ -101,7 -101,7 +102,7 @@@
  cpupower_install:
  	$(call descend,power/$(@:_install=),install)
  
- cgroup_install firewire_install gpio_install hv_install iio_install perf_install spi_install usb_install virtio_install vm_install bpf_install objtool_install:
 -cgroup_install firewire_install gpio_install hv_install iio_install perf_install spi_install usb_install virtio_install vm_install net_install objtool_install wmi_install:
++cgroup_install firewire_install gpio_install hv_install iio_install perf_install spi_install usb_install virtio_install vm_install bpf_install objtool_install wmi_install:
  	$(call descend,$(@:_install=),install)
  
  liblockdep_install:
@@@ -125,8 -125,9 +126,9 @@@ kvm_stat_install
  install: acpi_install cgroup_install cpupower_install gpio_install \
  		hv_install firewire_install iio_install liblockdep_install \
  		perf_install selftests_install turbostat_install usb_install \
 -		virtio_install vm_install net_install x86_energy_perf_policy_install \
 +		virtio_install vm_install bpf_install x86_energy_perf_policy_install \
- 		tmon_install freefall_install objtool_install kvm_stat_install
+ 		tmon_install freefall_install objtool_install kvm_stat_install \
+ 		wmi_install
  
  acpi_clean:
  	$(call descend,power/acpi,clean)
@@@ -134,7 -135,7 +136,7 @@@
  cpupower_clean:
  	$(call descend,power/cpupower,clean)
  
- cgroup_clean hv_clean firewire_clean spi_clean usb_clean virtio_clean vm_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean:
 -cgroup_clean hv_clean firewire_clean spi_clean usb_clean virtio_clean vm_clean wmi_clean net_clean iio_clean gpio_clean objtool_clean leds_clean:
++cgroup_clean hv_clean firewire_clean spi_clean usb_clean virtio_clean vm_clean wmi_clean bpf_clean iio_clean gpio_clean objtool_clean leds_clean:
  	$(call descend,$(@:_clean=),clean)
  
  liblockdep_clean:
@@@ -170,8 -171,8 +172,8 @@@ build_clean
  
  clean: acpi_clean cgroup_clean cpupower_clean hv_clean firewire_clean \
  		perf_clean selftests_clean turbostat_clean spi_clean usb_clean virtio_clean \
 -		vm_clean net_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
 +		vm_clean bpf_clean iio_clean x86_energy_perf_policy_clean tmon_clean \
  		freefall_clean build_clean libbpf_clean libsubcmd_clean liblockdep_clean \
- 		gpio_clean objtool_clean leds_clean
+ 		gpio_clean objtool_clean leds_clean wmi_clean
  
  .PHONY: FORCE