- 09 Jun, 2017 36 commits
-
-
Robin Murphy authored
Before making any DMA API calls, the ETR driver should really be setting its masks to ensure that DMA is possible. Especially since it can address more than the 32-bit default mask set by the AMBA bus code. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Tested-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Markus Elfring authored
Delete a character in this description for a condition check. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdfSigned-off-by:
-
Leo Yan authored
Almost low level functions from open firmware have used const to qualify device_node structures, so add const for device_node parameters in of_coresight related functions. Signed-off-by:
Leo Yan <leo.yan@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Leo Yan authored
In current code the output logs are not well symmetric for sink and link enabling and disabling. This patch is to fix that so can output paired logs. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
With 4.11-rc4, the following command triggers a WARN_ON, when a sink is not enabled. perf record -e cs_etm/@20010000.etf/ [88286.547741] ------------[ cut here ]------------ [88286.552332] WARNING: CPU: 3 PID: 2156 at kernel/workqueue.c:1442 __queue_work+0x29c/0x3b8 [88286.560427] Modules linked in: [88286.563451] [88286.564928] CPU: 3 PID: 2156 Comm: perf_v4.11 Not tainted 4.11.0-rc4 #217 [88286.573453] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Aug 15 2016 [88286.584128] task: ffff80097597c200 task.stack: ffff8009768b0000 [88286.589990] PC is at __queue_work+0x29c/0x3b8 [88286.594303] LR is at __queue_work+0x104/0x3b8 [88286.598614] pc : [<ffff0000080d8c7c>] lr : [<ffff0000080d8ae4>] pstate: a00001c5 [88286.605934] sp : ffff8009768b3aa0 [88286.609212] x29: ffff8009768b3aa0 x28: ffff80097ff3da00 [88286.614477] x27: ffff80097ff89c00 x26: ffff8009751b0e00 [88286.619741] x25: ffff000008c9f000 x24: 0000000000000003 [88286.625004] x23: 0000000000000040 x22: ffff000008d3dab8 [88286.630268] x21: ffff800977804400 x20: 0000000000000007 [88286.635532] x19: ffff000008c54000 x18: 0000fffff9185160 [88286.640795] x17: 0000ffffb33d9a38 x16: ffff000008088270 [88286.646059] x15: 0000ffffb345b590 x14: 0000000000000000 [88286.651322] x13: 0000000000000004 x12: 0000000000000040 [88286.656586] x11: 0000000000000068 x10: 0000000000000000 [88286.661849] x9 : ffff800977400028 x8 : 0000000000000000 [88286.667113] x7 : 0000000000000000 x6 : ffff0000080d8ae4 [88286.672376] x5 : 0000000000000000 x4 : 0000000000000080 [88286.677639] x3 : 0000000000000000 x2 : 0000000000000000 [88286.682903] x1 : 0000000000000000 x0 : ffff8009751b0e08 [88286.688166] [88286.689638] ---[ end trace 31633f18fd33d4cb ]--- [88286.694206] Call trace: [88286.696627] Exception stack(0xffff8009768b38d0 to 0xffff8009768b3a00) [88286.703004] 38c0: ffff000008c54000 0001000000000000 [88286.710757] 38e0: ffff8009768b3aa0 ffff0000080d8c7c ffff8009768b3b50 ffff80097ff8a5b0 [88286.718511] 3900: 0000800977325000 0000000000000000 0000000000000040 ffff80097ffc6180 [88286.726264] 3920: ffff8009768b3940 ffff0000088a8694 ffff80097ffc5800 0000000000000000 [88286.734017] 3940: ffff8009768b3960 ffff0000081919c0 ffff80097ffc5280 0000000000000001 [88286.741771] 3960: ffff8009768b3a50 ffff00000819206c ffff8009751b0e08 0000000000000000 [88286.749523] 3980: 0000000000000000 0000000000000000 0000000000000080 0000000000000000 [88286.757277] 39a0: ffff0000080d8ae4 0000000000000000 0000000000000000 ffff800977400028 [88286.765029] 39c0: 0000000000000000 0000000000000068 0000000000000040 0000000000000004 [88286.772783] 39e0: 0000000000000000 0000ffffb345b590 ffff000008088270 0000ffffb33d9a38 [88286.780537] [<ffff0000080d8c7c>] __queue_work+0x29c/0x3b8 [88286.785883] [<ffff0000080d8df8>] queue_work_on+0x60/0x78 [88286.791146] [<ffff000008764c68>] etm_setup_aux+0x178/0x238 [88286.796578] [<ffff000008183600>] rb_alloc_aux+0x228/0x310 [88286.801925] [<ffff00000817e564>] perf_mmap+0x404/0x5a8 [88286.807015] [<ffff0000081c60cc>] mmap_region+0x394/0x5c0 [88286.812276] [<ffff0000081c654c>] do_mmap+0x254/0x388 [88286.817191] [<ffff0000081a989c>] vm_mmap_pgoff+0xbc/0xe0 [88286.822452] [<ffff0000081c3ffc>] SyS_mmap_pgoff+0xac/0x228 [88286.827884] [<ffff000008088288>] sys_mmap+0x18/0x28 [88286.832714] [<ffff000008082f30>] el0_svc_naked+0x24/0x28 The patch makes sure that the event_data->work is initialised properly before we could possibly use it. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
Mike Leach <mike.leach@linaro.org> Signed-off-by:
-
Suzuki K Poulose authored
For software sources (i.e STM), there could be multiple agents generating the trace data, unlike the ETMs. So we need to properly do the accounting for the active number of users to disable the device when the last user goes away. Right now, the reference counting is broken for sources as we skip the actions when we detect that the source is enabled. This patch fixes the problem by adding the refcounting for software sources, even when they are enabled. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Reported-by:
Robert Walker <robert.walker@arm.com> Signed-off-by:
-
Suzuki K Poulose authored
With a coresight tracing session, the components along the path from the source to sink are disabled after the source is disabled. However, if the source was not actually disabled due to active users, we should not disable the components in the path. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in tb_sw_warn warning message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Mika Westerberg authored
We will be helping Andreas to maintain the Thunderbolt driver. Signed-off-by:
Michael Jamet <michael.jamet@intel.com> Signed-off-by:
Yehezkel Bernat <yehezkel.bernat@intel.com> Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Andreas Noever <andreas.noever@gmail.com> Signed-off-by:
-
Mika Westerberg authored
Since there are no such tool yet that handles all the low-level details of connecting devices and upgrading their firmware, add a small document that shows how the Thunderbolt bus can be used directly from command line. Signed-off-by:
-
Mika Westerberg authored
Starting from Intel Falcon Ridge the NVM firmware can be upgraded by using DMA configuration based mailbox commands. If we detect that the host or device (device support starts from Intel Alpine Ridge) has the DMA configuration based mailbox we expose NVM information to the userspace as two separate Linux NVMem devices: nvm_active and nvm_non_active. The former is read-only portion of the active NVM which firmware upgrade tools can be use to find out suitable NVM image if the device identification strings are not enough. The latter is write-only portion where the new NVM image is to be written by the userspace. It is up to the userspace to find out right NVM image (the kernel does very minimal validation). The ICM firmware itself authenticates the new NVM firmware and fails the operation if it is not what is expected. We also expose two new sysfs files per each switch: nvm_version and nvm_authenticate which can be used to read the active NVM version and start the upgrade process. We also introduce safe mode which is the mode a switch goes when it does not have properly authenticated firmware. In this mode the switch only accepts a couple of commands including flashing a new NVM firmware image and triggering power cycle. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
Starting from Intel Falcon Ridge the internal connection manager running on the Thunderbolt host controller has been supporting 4 security levels. One reason for this is to prevent DMA attacks and only allow connecting devices the user trusts. The internal connection manager (ICM) is the preferred way of connecting Thunderbolt devices over software only implementation typically used on Macs. The driver communicates with ICM using special Thunderbolt ring 0 (control channel) messages. In order to handle these messages we add support for the ICM messages to the control channel. The security levels are as follows: none - No security, all tunnels are created automatically user - User needs to approve the device before tunnels are created secure - User need to approve the device before tunnels are created. The device is sent a challenge on future connects to be able to verify it is actually the approved device. dponly - Only Display Port and USB tunnels can be created and those are created automatically. The security levels are typically configurable from the system BIOS and by default it is set to "user" on many systems. In this patch each Thunderbolt device will have either one or two new sysfs attributes: authorized and key. The latter appears for devices that support secure connect. In order to identify the device the user can read identication information, including UUID and name of the device from sysfs and based on that make a decision to authorize the device. The device is authorized by simply writing 1 to the "authorized" sysfs attribute. This is following the USB bus device authorization mechanism. The secure connect requires an additional challenge step (writing 2 to the "authorized" attribute) in future connects when the key has already been stored to the NVM of the device. Non-ICM systems (before Alpine Ridge) continue to use the existing functionality and the security level is set to none. For systems with Alpine Ridge, even on Apple hardware, we will use ICM. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by: -
Mika Westerberg authored
On PCs the NHI host controller is only present when there is a device connected. When the last device is disconnected the host controller will dissappear shortly (within 10s). Now if that happens when we are suspended we should not try to touch the hardware anymore, so add a flag for this and check it before we re-enable rings. Signed-off-by:
-
Mika Westerberg authored
The DMA (NHI) port of a switch provides access to the NVM of the host controller (and devices starting from Intel Alpine Ridge). The NVM contains also more complete DROM for the root switch including vendor and device identification strings. This will look for the DMA port capability for each switch and if found populates sw->dma_port. We then teach tb_drom_read() to read the DROM information from NVM if available for the root switch. The DMA port capability also supports upgrading the NVM for both host controller and devices which will be added in subsequent patches. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
In some cases it is useful to know what is the Thunderbolt generation the switch supports. This introduces a new field to struct switch that stores the generation of the switch based on the device ID. Unknown switches (there should be none) are assumed to be first generation to be on the safe side. Signed-off-by:
-
Mika Westerberg authored
The host controller includes two sets of registers that are used to communicate with the firmware. Add functions that can be used to access these registers. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
Add Intel Win Ridge (Thunderbolt 2) and Alpine Ridge (Thunderbolt 3) controller PCI IDs to the list of supported devices. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
If a request times out the response might arrive right after the request is failed. This response is pushed to the kfifo and next request will read it instead. Since it most likely will not pass our validation checks in parse_header() the next request will fail as well, and response to that request will be pushed to the kfifo, ad infinitum. We end up in a situation where all requests fail and no devices can be added anymore until the driver is unloaded and reloaded again. To overcome this, rework the control channel so that we will have a queue of outstanding requests. Each request will be handled in turn and the response is validated against what is expected. Unexpected packets (for example responses for requests that have been timed out) are dropped. This model is copied from Greybus implementation with small changes here and there to get it cope with Thunderbolt control packets. In addition the configuration packets support sequence number which the switch is supposed to copy from the request to response. We use this to drop responses that are already timed out. Taking advantage of the sequence number, we automatically retry configuration read/write 4 times before giving up. Also timeout is not a programming error so there is no need to trigger a scary backtrace (WARN), instead we just log a warning. After all Thunderbolt devices are hot-pluggable by definition which means user can unplug a device any time and that is totally acceptable. With this change there is no need to take the global domain lock when sending configuration packets anymore. This is useful when we add support for cross-domain (XDomain) communication later on. Signed-off-by:
-
Mika Westerberg authored
Currently the control channel (ctl.c) handles the one supported notification (PLUG_EVENT) and sends back ACK accordingly. However, we are going to add support for the internal connection manager (ICM) that needs to handle a different notifications. So instead of dealing everything in the control channel, we change the callback to take an arbitrary thunderbolt packet and convert the native connection manager to handle the event itself. In addition we only push replies we know of to the response FIFO. Everything else is treated as notification (or request) and is expected to be dealt by the connection manager implementation. Signed-off-by:
-
Mika Westerberg authored
We will be using this function in files introduced in subsequent patches. While there the function is renamed to tb_cfg_make_header() following tb_cfg_get_route(). Signed-off-by:
-
Mika Westerberg authored
We are going to use it when we change the connection manager to handle events itself. Also rename it to follow naming convention used in functions exposed in ctl.h. Signed-off-by:
-
Mika Westerberg authored
We will be forwarding notifications received from the control channel to the connection manager implementations. This way they can decide what to do if anything when a notification is received. To be able to use control channel messages from other files, move them to tb_msgs.h. No functional changes intended. Signed-off-by:
-
Mika Westerberg authored
The device DROM contains name of the vendor and device among other things. Extract this information and expose it to the userspace via two new attributes. Signed-off-by:
-
Lukas Wunner authored
Currently tb_drom_parse_entry() is only able to parse drom entries of type TB_DROM_ENTRY_PORT. Rename it to tb_drom_parse_entry_port(). Fold tb_drom_parse_port_entry() into it. Its return value is currently ignored. Evaluate it and abort parsing on error. Change tb_drom_parse_entries() to accommodate for parsing of other entry types than TB_DROM_ENTRY_PORT. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Mika Westerberg authored
There are devices out there where CRC32 of the DROM is not correct. One reason for this is that the ICM firmware does not validate it and it seems that neither does the Apple driver. To be able to support such devices we continue parsing the DROM contents regardless of whether CRC32 failed or not. We still keep the warning there. Signed-off-by:
-
Mika Westerberg authored
All non-root switches are expected to have DROM so if the operation fails, it might be due the user unlugging the device. There is no point continuing adding the switch further in that case. Just bail out. For root switches (hosts) the DROM is either retrieved from a EFI variable, NVM or hard-coded. Signed-off-by:
-
Mika Westerberg authored
Thunderbolt domain consists of switches that are connected to each other, forming a bus. This will convert each switch into a real Linux device structure and adds them to the domain. The advantage here is that we get all the goodies from the driver core, like reference counting and sysfs hierarchy for free. Also expose device identification information to the userspace via new sysfs attributes. In order to support internal connection manager (ICM) we separate switch configuration into its own function (tb_switch_configure()) which is only called by the existing native connection manager implementation used on Macs. Signed-off-by:
-
Mika Westerberg authored
Thunderbolt fabric consists of one or more switches. This fabric is called domain and it is controlled by an entity called connection manager. The connection manager can be either internal (driven by a firmware running on the host controller) or external (software driver). This driver currently implements support for the latter. In order to manage switches and their properties more easily we model this domain structure as a Linux bus. Each host controller adds a domain device to this bus, and these devices are named as domainN where N stands for index or id of the current domain. We then abstract connection manager specific operations into a new structure tb_cm_ops and convert the existing tb.c to fill those accordingly. This makes it easier to add support for the internal connection manager in subsequent patches. Signed-off-by:
-
Mika Westerberg authored
Following the usual pattern used in many places, we allow passing NULL pointer to tb_ctl_free(). Then the user can call the function regardless if it has allocated control channel or not making the code bit simpler. Suggested-by:
-
Mika Westerberg authored
Organization of the capabilities in switches and ports is not so random after all. Rework the capability handling functionality so that it follows how capabilities are organized and provide two new functions (tb_switch_find_vse_cap() and tb_port_find_cap()) which can be used to extract capabilities for ports and switches. Then convert the current users over these. Signed-off-by:
-
Mika Westerberg authored
Intel Thunderbolt controllers support up to 16 MSI-X vectors. Using MSI-X is preferred over MSI or legacy interrupt and may bring additional performance because there is no need to check the status registers which interrupt was triggered. While there we convert comments in structs tb_ring and tb_nhi to follow kernel-doc format more closely. This code is based on the work done by Amir Levy and Michael Jamet. Signed-off-by:
-
Mika Westerberg authored
DROM version 2 is compatible with the previous generation so no need to warn about that. Signed-off-by:
-
Mika Westerberg authored
At least Falcon Ridge when in host mode does not have any kind of DROM available and reading DROM offset returns 0 for these. Do not try to read DROM any further in that case. Signed-off-by:
-
Mika Westerberg authored
The root switch is part of the host controller and cannot be physically removed, so there is no point of reading UID again on resume in order to check if the root switch is still the same. Suggested-by:
-
Mika Westerberg authored
These functions should not (and do not) modify the argument in any way so make it const. Signed-off-by:
-
- 03 Jun, 2017 4 commits
-
-
Philipp Zabel authored
This adds a driver for mmio-based syscon multiplexers controlled by bitfields in a syscon register range. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Philipp Zabel authored
This adds device tree binding documentation for mmio-based syscon multiplexers controlled by a bitfields in a syscon register range. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Peter Rosin authored
Analog Devices ADG792A/G is a triple 4:1 mux. Reviewed-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Peter Rosin authored
Analog Devices ADG792A/G is a triple 4:1 mux. Acked-by:
-
