summaryrefslogtreecommitdiff
path: root/drivers/net/thunderbolt.c
AgeCommit message (Collapse)Author
2019-04-18net: thunderbolt: Unregister ThunderboltIP protocol handler when suspendingMika Westerberg
The XDomain protocol messages may start as soon as Thunderbolt control channel is started. This means that if the other host starts sending ThunderboltIP packets early enough they will be passed to the network driver which then gets confused because its resume hook is not called yet. Fix this by unregistering the ThunderboltIP protocol handler when suspending and registering it back on resume. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: David S. Miller <davem@davemloft.net>
2018-08-29net: thunderbolt: Convert to use SPDX identifierMika Westerberg
This gets rid of the licence boilerblate in favor of SPDX identifier which only takes a single line comment. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12net: thunderbolt: Run disconnect flow asynchronously when logout is receivedMika Westerberg
The control channel calls registered callbacks when control messages such as XDomain protocol messages are received. The control channel handling is done in a worker running on system workqueue which means the networking driver can't run tear down flow which includes sending disconnect request and waiting for a reply in the same worker. Otherwise reply is never received (as the work is already running) and the operation times out. To fix this run disconnect ThunderboltIP flow asynchronously once ThunderboltIP logout message is received. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-12net: thunderbolt: Tear down connection properly on suspendMika Westerberg
When suspending to mem or disk the Thunderbolt controller typically goes down as well tearing down the connection automatically. However, when suspend to idle is used this does not happen so we need to make sure the connection is properly disconnected before it can be re-established during resume. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-25net: thunderbolt: Stop using zero to mean no valid DMA mappingMika Westerberg
Commit 86dabda426ac ("net: thunderbolt: Clear finished Tx frame bus address in tbnet_tx_callback()") fixed a DMA-API violation where the driver called dma_unmap_page() in tbnet_free_buffers() for a bus address that might already be unmapped. The fix was to zero out the bus address of a frame in tbnet_tx_callback(). However, as pointed out by David Miller, zero might well be valid mapping (at least in theory) so it is not good idea to use it here. It turns out that we don't need the whole map/unmap dance for Tx buffers at all. Instead we can map the buffers when they are initially allocated and unmap them when the interface is brought down. In between we just DMA sync the buffers for the CPU or device as needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-11net: thunderbolt: Clear finished Tx frame bus address in tbnet_tx_callback()Mika Westerberg
When Thunderbolt network interface is disabled or when the cable is unplugged the driver releases all allocated buffers by calling tbnet_free_buffers() for each ring. This function then calls dma_unmap_page() for each buffer it finds where bus address is non-zero. Now, we only clear this bus address when the Tx buffer is sent to the hardware so it is possible that the function finds an entry that has already been unmapped. Enabling DMA-API debugging catches this as well: thunderbolt 0000:06:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000068321000] [size=4096 bytes] Fix this by clearing the bus address of a Tx frame right after we have unmapped the buffer. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-19thunderbolt: Right shifting to zero bug in tbnet_handle_packet()Dan Carpenter
There is a problem when we do: sequence = pkg->hdr.length_sn & TBIP_HDR_SN_MASK; sequence >>= TBIP_HDR_SN_SHIFT; TBIP_HDR_SN_SHIFT is 27, and right shifting a u8 27 bits is always going to result in zero. The fix is to declare these variables as u32. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-02net: Add support for networking over Thunderbolt cableAmir Levy
ThunderboltIP is a protocol created by Apple to tunnel IP/ethernet traffic over a Thunderbolt cable. The protocol consists of configuration phase where each side sends ThunderboltIP login packets (the protocol is determined by UUID in the XDomain packet header) over the configuration channel. Once both sides get positive acknowledgment to their login packet, they configure high-speed DMA path accordingly. This DMA path is then used to transmit and receive networking traffic. This patch creates a virtual ethernet interface the host software can use in the same way as any other networking interface. Once the interface is brought up successfully network packets get tunneled over the Thunderbolt cable to the remote host and back. The connection is terminated by sending a ThunderboltIP logout packet over the configuration channel. We do this when the network interface is brought down by user or the driver is unloaded. Signed-off-by: Amir Levy <amir.jer.levy@intel.com> 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>