#
acb40d84 |
| 09-Oct-2017 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Initialize Thunderbolt bus earlier
The 0day kbuild robot reports following crash:
BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: tb_property_find+0xe/0x41
thunderbolt: Initialize Thunderbolt bus earlier
The 0day kbuild robot reports following crash:
BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: tb_property_find+0xe/0x41 *pde = 00000000 Oops: 0000 [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.0-rc1-00741-ge69b6c0 #412 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 task: 89c80000 task.stack: 89c7c000 EIP: tb_property_find+0xe/0x41 EFLAGS: 00210246 CPU: 0 EAX: 00000000 EBX: 7a368f47 ECX: 00000044 EDX: 7a368f47 ESI: 8851d340 EDI: 7a368f47 EBP: 89c7df0c ESP: 89c7defc DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 80050033 CR2: 00000004 CR3: 027a2000 CR4: 00000690 Call Trace: tb_register_property_dir+0x49/0xb9 ? cdc_mbim_driver_init+0x1b/0x1b tbnet_init+0x77/0x9f ? cdc_mbim_driver_init+0x1b/0x1b do_one_initcall+0x7e/0x145 ? parse_args+0x10c/0x1b3 ? kernel_init_freeable+0xbe/0x159 kernel_init_freeable+0xd1/0x159 ? rest_init+0x110/0x110 kernel_init+0xd/0xd0 ret_from_fork+0x19/0x30
The reason is that both Thunderbolt bus and thunderbolt-net are build into the kernel image, and the latter is linked first because drivers/net comes before drivers/thunderbolt. Since both use module_init() thunderbolt-net ends up calling Thunderbolt bus functions too early triggering the above crash.
Fix this by moving Thunderbolt bus initialization to happen earlier to make sure all the data structures are ready when Thunderbolt service drivers are initialized. To be on the safe side also add a check for properly initialized xdomain_property_dir to tb_register_property_dir().
Reported-by: kernel test robot <fengguang.wu@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
753d179a |
| 06-Oct-2017 |
Johannes Berg <johannes.berg@intel.com> |
Merge remote-tracking branch 'net-next/master' into mac80211-next
Merging this brings in the timer_setup() change, which allows me to apply Kees's mac80211 changes for it.
Signed-off-by: Johannes B
Merge remote-tracking branch 'net-next/master' into mac80211-next
Merging this brings in the timer_setup() change, which allows me to apply Kees's mac80211 changes for it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
show more ...
|
#
c4b3630a |
| 02-Oct-2017 |
David S. Miller <davem@davemloft.net> |
Merge branch 'Thunderbolt-networking'
Mika Westerberg says:
==================== Thunderbolt networking
In addition of tunneling PCIe, Display Port and USB traffic, Thunderbolt allows connecting t
Merge branch 'Thunderbolt-networking'
Mika Westerberg says:
==================== Thunderbolt networking
In addition of tunneling PCIe, Display Port and USB traffic, Thunderbolt allows connecting two hosts (domains) over a Thunderbolt cable. It is possible to tunnel arbitrary data packets over such connection using high-speed DMA rings available in the Thunderbolt host controller.
In order to discover Thunderbolt services the other host supports, there is a software protocol running on top of the automatically configured control channel (ring 0). This protocol is called XDomain discovery protocol and it uses XDomain properties to describe the host (domain) and the services it supports.
Once both sides have agreed what services are supported they can enable high-speed DMA rings to transfer data over the cable.
This series adds support for the XDomain protocol so that we expose each remote connection as Thunderbolt XDomain device and each service as Thunderbolt service device. On top of that we create an API that allows writing drivers for these services and finally we provide an example Thunderbolt service driver that creates virtual ethernet inferface that allows tunneling networking packets over Thunderbolt cable. The API could be used for creating other future Thunderbolt services, such as tunneling SCSI over Thunderbolt, for example.
The XDomain protocol and networking support is also available in macOS and Windows so this makes it possible to connect Linux to macOS and Windows as well.
The patches are based on previous Thunderbolt networking patch series by Amir Levy and Michael Jamet, that can be found here:
https://lwn.net/Articles/705998/
The main difference to that patch series is that we have the XDomain protocol running in the kernel now so there is no need for a separate userspace daemon.
Note this does not affect the existing functionality, so security levels and NVM firmware upgrade continue to work as before (with the small exception that now sysfs also shows the XDomain connections and services in addition to normal Thunderbolt devices). It is also possible to connect up to 5 Thunderbolt devices and then another host, and the network driver works exactly the same.
This is third version of the patch series. The previous versions can be be found here:
v2: https://lkml.org/lkml/2017/9/25/225 v1: https://lwn.net/Articles/734019/
Changes from the v2:
* Add comment regarding calculation of interrupt throttling value * Add UUIDs as strings in comments on top of each declaration * Add a patch removing __packed from existing ICM messages. They are all 32-bit aligned and should pack fine without the __packed. * Move adding MAINTAINERS entries to a separate patches * Added Michael and Yehezkel to be maintainers of the network driver * Remove __packed from the new ICM messages. They should pack fine as well without it. * Call register_netdev() after all other initialization is done in the network driver. * Use build_skb() instead of copying. We allocate order 1 page here to leave room for SKB shared info required by build_skb(). However, we do not leave room for full NET_SKB_PAD because the NHI hardware does not cope well if a frame crosses 4kB boundary. According comments in __build_skb() that should still be fine. * Added Reviewed-by tag from Andy.
Changes from the v1:
* Add include/linux/thunderbolt.h to MAINTAINERS * Correct Linux version and date of new sysfs entries in Documentation/ABI/testing/sysfs-bus-thunderbolt * Move network driver from drivers/thunderbolt/net.c to drivers/net/thunderbolt.c and update it to follow coding style in drivers/net/*. * Add MAINTAINERS entry for the network driver * Minor cleanups
In case someone wants to try this out, the last patch adds documentation how the networking driver can be used. In short, if you connect Linux to a macOS or Windows, everything is done automatically (as those systems have the networking service enabled by default). For Linux to Linux connection one host needs to load the networking driver first (so that the other side can locate the networking service and load the corresponding driver). ====================
Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d1ff7024 |
| 02-Oct-2017 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Add support for XDomain discovery protocol
When two hosts are connected over a Thunderbolt cable, there is a protocol they can use to communicate capabilities supported by the host. The
thunderbolt: Add support for XDomain discovery protocol
When two hosts are connected over a Thunderbolt cable, there is a protocol they can use to communicate capabilities supported by the host. The discovery protocol uses automatically configured control channel (ring 0) and is build on top of request/response transactions using special XDomain primitives provided by the Thunderbolt base protocol.
The capabilities consists of a root directory block of basic properties used for identification of the host, and then there can be zero or more directories each describing a Thunderbolt service and its capabilities.
Once both sides have discovered what is supported the two hosts can setup high-speed DMA paths and transfer data to the other side using whatever protocol was agreed based on the properties. The software protocol used to communicate which DMA paths to enable is service specific.
This patch adds support for the XDomain discovery protocol to the Thunderbolt bus. We model each remote host connection as a Linux XDomain device. For each Thunderbolt service found supported on the XDomain device, we create Linux Thunderbolt service device which Thunderbolt service drivers can then bind to based on the protocol identification information retrieved from the property directory describing the service.
This code is based on the work done by Amir Levy and Michael Jamet.
Signed-off-by: Michael Jamet <michael.jamet@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|