aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/misc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-02-25misc/mei/hdcp: Verify Receiver Cert and prepare kmRamalingam C1-1/+82
Requests for verification for receiver certification and also the preparation for next AKE auth message with km. On Success ME FW validate the HDCP2.2 receivers certificate and do the revocation check on the receiver ID. AKE_Stored_Km will be prepared if the receiver is already paired, else AKE_No_Stored_Km will be prepared. Here AKE_Stored_Km and AKE_No_Stored_Km are HDCP2.2 protocol msgs. v2: Rebased. v3: cldev is passed as first parameter [Tomas] Redundant comments and cast are removed [Tomas] v4: %zd is used for ssize_t [Alexander] %s/return -1/return -EIO [Alexander] v5: Rebased. v6: Collected the Rb-ed by. Rebasing. v7: Adjust to the new mei interface. Fix for Kdoc. v8: K-Doc Addition. [Tomas] memcpy for const length. v9: renamed func as mei_hdcp_* [Tomas] Inline function is defined for DDI index [Tomas] v10: Fixed the conversion of u8 to bool [Tomas] K-Doc fix [Tomas] v11: Rebased. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-6-git-send-email-ramalingam.c@intel.com
2019-02-25misc/mei/hdcp: Initiate Wired HDCP2.2 Tx SessionRamalingam C2-0/+105
Request ME FW to start the HDCP2.2 session for an intel port. Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends to ME FW. On Success, ME FW will start a HDCP2.2 session for the port and provides the content for HDCP2.2 AKE_Init message. v2: Rebased. v3: cldev is add as a separate parameter [Tomas] Redundant comment and typecast are removed [Tomas] v4: %zd is used for size [Alexander] %s/return -1/return -EIO [Alexander] Spellings in commit msg is fixed [Uma] v5: Rebased. v6: Collected the rb-ed by. Realigning the patches in the series. v7: Adjust to the new mei interface. Fix for kdoc. v8: K-Doc Addition. memcpy for const length. v9: s/mei_hdcp_ddi/mei_fw_ddi s/i915_port/mei_i915_port [Tomas] renamed func as mei_hdcp_* [Tomas] Instead of macro, inline func for ddi index is used. [Tomas] v10: Switch case for the coversion between i915_port to mei_ddi [Tomas] Kernel doc fix. v11: mei_hdcp_ops is defined as const. [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-5-git-send-email-ramalingam.c@intel.com
2019-02-25misc/mei/hdcp: Define ME FW interface for HDCP2.2Ramalingam C1-0/+366
Defines the HDCP specific ME FW interfaces such as Request CMDs, payload structure for CMDs and their response status codes. This patch defines payload size(Excluding the Header)for each WIRED HDCP2.2 CMDs. v2: Rebased. v3: Extra comments are removed. v4: %s/\/\*\*/\/\* v5: Extra lines are removed. v6: Remove redundant text from the License header %s/LPRIME_HALF/V_PRIME_HALF %s/uintxx_t/uxx v7: Extra taps removed. v8: k is defined as __be16 [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-4-git-send-email-ramalingam.c@intel.com
2019-02-25misc/mei/hdcp: Client driver for HDCP applicationRamalingam C4-0/+83
ME FW contributes a vital role in HDCP2.2 authentication. HDCP2.2 driver needs to communicate to ME FW for each step of the HDCP2.2 authentication. ME FW prepare and HDCP2.2 authentication parameters and encrypt them as per spec. With such parameter Driver prepares HDCP2.2 auth messages and communicate with HDCP2.2 sink. Similarly HDCP2.2 sink's response is shared with ME FW for decrypt and verification. Once All the steps of HDCP2.2 authentications are complete on driver's request ME FW will configure the port as authenticated and supply the HDCP keys to the Gen HW for encryption. Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption for a port. ME FW is interfaced to kernel through MEI Bus Driver. To obtain the HDCP2.2 services from the ME FW through MEI Bus driver MEI Client Driver is developed. v2: hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas] v3: Squashed the Kbuild support [Tomas] UUID renamed and Module License is modified [Tomas] drv_data is set to null at remove [Tomas] v4: Module name is changed to "MEI HDCP" I915 Selects the MEI_HDCP v5: Remove redundant text from the License header Fix malformed licence Removed the drv_data resetting. v6: K-Doc addition. [Tomas] v7: %s/UUID_LE/GUID_INIT [Tomas] GPL Ver is 2.0 than 2.0+ [Tomas] v8: Added more info into Kconfig addition [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-3-git-send-email-ramalingam.c@intel.com
2019-02-25mei: bus: whitelist hdcp clientTomas Winkler1-0/+16
Whitelist HDCP client for in kernel drm use v2: Rebased. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550772730-23280-2-git-send-email-ramalingam.c@intel.com
2019-02-23habanalabs: driver's Kconfig must select DMA_SHARED_BUFFEROded Gabbay1-0/+1
The driver uses the DMA_BUF module which is built only if DMA_SHARED_BUFFER is selected. DMA_SHARED_BUFFER doesn't have any dependencies so it is ok to select it (as done by many other components). Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-23habanalabs: don't print result when rc indicates errorOded Gabbay1-4/+10
send_cpu_message() doesn't update the result parameter when an error occurs in its code. Therefore, callers of send_cpu_message() shouldn't use the result value when the return code indicates error. This patch fixes a static checker warning in goya_test_cpu_queue(), where that function did print the result even though the return code from send_cpu_message() indicated error. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-22habanalabs: use GFP_ATOMIC under spin lockWei Yongjun1-1/+1
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 0feaf86d4e69 ("habanalabs: add virtual memory and MMU modules") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-21Merge branch 'topic/dma' into nextMichael Ellerman1-2/+1
Merge hch's big DMA rework series. This is in a topic branch in case he wants to merge it to minimise conflicts.
2019-02-21misc: pci_endpoint_test: Add the layerscape EP device supportXiaowei Bao1-0/+1
Add the layerscape EP device support in pci_endpoint_test driver. Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Minghuan Lian <minghuan.lian@nxp.com> Reviewed-by: Zhiqiang Hou <zhiqiang.hou@nxp.com> Reviewed-by: Greg KH <gregkh@linuxfoundation.org>
2019-02-20mei: hbm: clean the feature flags on link resetAlexander Usyskin1-0/+7
The list of supported functions can be altered upon link reset, clean the flags to allow correct selections of supported features. Cc: <stable@vger.kernel.org> v4.19+ Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19misc: fastrpc: Fix return value check in fastrpc_map_create()Wei Yongjun1-2/+2
In case of error, the function dma_buf_get() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19misc: fastrpc: Fix device_open when no session is availableThierry Escande1-1/+10
This change fixes fastrpc_device_open() when no session is available and return an error in such case. Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-19misc: fastrpc: select CONFIG_DMA_SHARED_BUFFERSrinivas Kandagatla1-0/+1
Fastrpc is a dma buf exporter as well, so select the corresponding DMA_SHARED_BUFFER config to fix below compilation errors on platforms without this config. ld: drivers/misc/fastrpc.o: in function 'fastrpc_free_map': fastrpc.c:(.text+0xbe): undefined reference to 'dma_buf_unmap_attachment' ld: fastrpc.c:(.text+0xcb): undefined reference to 'dma_buf_detach' ld: fastrpc.c:(.text+0xd4): undefined reference to 'dma_buf_put' ld: drivers/misc/fastrpc.o: in function 'fastrpc_map_create': fastrpc.c:(.text+0xb2b): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0xb47): undefined reference to 'dma_buf_attach' ld: fastrpc.c:(.text+0xb61): undefined reference to 'dma_buf_map_attachment' ld: fastrpc.c:(.text+0xc36): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0xc48): undefined reference to 'dma_buf_detach' ld: drivers/misc/fastrpc.o: in function 'fastrpc_device_ioctl': fastrpc.c:(.text+0x1756): undefined reference to 'dma_buf_get' ld: fastrpc.c:(.text+0x1776): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1780): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1abf): undefined reference to 'dma_buf_export' ld: fastrpc.c:(.text+0x1ae7): undefined reference to 'dma_buf_fd' ld: fastrpc.c:(.text+0x1cb5): undefined reference to 'dma_buf_put' ld: fastrpc.c:(.text+0x1cca): undefined reference to 'dma_buf_put' Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18powerpc/dma: remove set_dma_offsetChristoph Hellwig1-1/+1
There is no good reason for this helper, just opencode it. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-18powerpc/dma: use the generic direct mapping bypassChristoph Hellwig1-1/+0
Now that we've switched all the powerpc nommu and swiotlb methods to use the generic dma_direct_* calls we can remove these ops vectors entirely and rely on the common direct mapping bypass that avoids indirect function calls entirely. This also allows to remove a whole lot of boilerplate code related to setting up these operations. Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2019-02-18habanalabs: add debugfs supportOded Gabbay10-2/+1420
This patch adds debugfs support to the driver. It allows the user-space to display information that is contained in the internal structures of the driver, such as: - active command submissions - active user virtual memory mappings - number of allocated command buffers It also enables the user to perform reads and writes through Goya's PCI bars. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: implement INFO IOCTLOded Gabbay3-0/+134
This patch implements the INFO IOCTL. That IOCTL is used by the user to query information that is relevant/needed by the user in order to submit deep learning jobs to Goya. The information is divided into several categories, such as H/W IP, Events that happened, DDR usage and more. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add virtual memory and MMU modulesOmer Shpigelman11-7/+2892
This patch adds the Virtual Memory and MMU modules. Goya has an internal MMU which provides process isolation on the internal DDR. The internal MMU also performs translations for transactions that go from Goya to the Host. The driver is responsible for allocating and freeing memory on the DDR upon user request. It also provides an interface to map and unmap DDR and Host memory to the device address space. The MMU in Goya supports 3-level and 4-level page tables. With 3-level, the size of each page is 2MB, while with 4-level the size of each page is 4KB. In the DDR, the physical pages are always 2MB. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add command submission moduleOded Gabbay10-6/+2686
This patch adds the main flow for the user to submit work to the device. Each work is described by a command submission object (CS). The CS contains 3 arrays of command buffers: One for execution, and two for context-switch (store and restore). For each CB, the user specifies on which queue to put that CB. In case of an internal queue, the entry doesn't contain a pointer to the CB but the address in the on-chip memory that the CB resides at. The driver parses some of the CBs to enforce security restrictions. The user receives a sequence number that represents the CS object. The user can then query the driver regarding the status of the CS, using that sequence number. In case the CS doesn't finish before the timeout expires, the driver will perform a soft-reset of the device. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add device reset supportOded Gabbay10-25/+737
This patch adds support for doing various on-the-fly reset of Goya. The driver supports two types of resets: 1. soft-reset 2. hard-reset Soft-reset is done when the device detects a timeout of a command submission that was given to the device. The soft-reset process only resets the engines that are relevant for the submission of compute jobs, i.e. the DMA channels, the TPCs and the MME. The purpose is to bring the device as fast as possible to a working state. Hard-reset is done in several cases: 1. After soft-reset is done but the device is not responding 2. When fatal errors occur inside the device, e.g. ECC error 3. When the driver is removed Hard-reset performs a reset of the entire chip except for the PCI controller and the PLLs. It is a much longer process then soft-reset but it helps to recover the device without the need to reboot the Host. After hard-reset, the driver will restore the max power attribute and in case of manual power management, the frequencies that were set. This patch also adds two entries to the sysfs, which allows the root user to initiate a soft or hard reset. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add sysfs and hwmon supportOded Gabbay10-2/+1699
This patch add the sysfs and hwmon entries that are exposed by the driver. Goya has several sensors, from various categories such as temperature, voltage, current, etc. The driver exposes those sensors in the standard hwmon mechanism. In addition, the driver exposes a couple of interfaces in sysfs, both for configuration and for providing status of the device or driver. The configuration attributes is for Power Management: - Automatic or manual - Frequency value when moving to high frequency mode - Maximum power the device is allowed to consume The rest of the attributes are read-only and provide the following information: - Versions of the various firmwares running on the device - Contents of the device's EEPROM - The device type (currently only Goya is supported) - PCI address of the device (to allow user-space to connect between /dev/hlX to PCI address) - Status of the device (operational, malfunction, in_reset) - How many processes are open on the device's file Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add event queue and interruptsOded Gabbay6-13/+694
This patch adds support for receiving events from Goya's control CPU and for receiving MSI-X interrupts from Goya's DMA engines and CPU. Goya's PCI controller supports up to 8 MSI-X interrupts, which only 6 of them are currently used. The first 5 interrupts are dedicated for Goya's DMA engine queues. The 6th interrupt is dedicated for Goya's control CPU. The DMA queue will signal its MSI-X entry upon each completion of a command buffer that was placed on its primary queue. The driver will then mark that CB as completed and free the related resources. It will also update the command submission object which that CB belongs to. There is a dedicated event queue (EQ) between the driver and Goya's control CPU. The EQ is located on the Host memory. The control CPU writes a new entry to the EQ for various reasons, such as ECC error, MMU page fault, Hot temperature. After writing the new entry to the EQ, the control CPU will trigger its dedicated MSI-X entry to signal the driver that there is a new entry in the EQ. The driver will then read the entry and act accordingly. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add h/w queues moduleOded Gabbay12-8/+2778
This patch adds the H/W queues module and the code to initialize Goya's various compute and DMA engines and their queues. Goya has 5 DMA channels, 8 TPC engines and a single MME engine. For each channel/engine, there is a H/W queue logic which is used to pass commands from the user to the H/W. That logic is called QMAN. There are two types of QMANs: external and internal. The DMA QMANs are considered external while the TPC and MME QMANs are considered internal. For each external queue there is a completion queue, which is located on the Host memory. The differences between external and internal QMANs are: 1. The location of the queue's memory. External QMANs are located on the Host memory while internal QMANs are located on the on-chip memory. 2. The external QMAN write an entry to a completion queue and sends an MSI-X interrupt upon completion of a command buffer that was given to it. The internal QMAN doesn't do that. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add basic Goya h/w initializationOded Gabbay10-8/+3991
This patch adds the basic part of Goya's H/W initialization. It adds code that initializes Goya's internal CPU, various registers that are related to internal routing, scrambling, workarounds for H/W bugs, etc. It also initializes Goya's security scheme that prevents the user from abusing Goya to steal data from the host, crash the host, change Goya's F/W, etc. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add command buffer moduleOded Gabbay7-2/+692
This patch adds the command buffer (CB) module, which allows the user to create and destroy CBs and to map them to the user's process address-space. A command buffer is a memory blocks that reside in DMA-able address-space and is physically contiguous so it can be accessed by the device without MMU translation. The command buffer memory is allocated using the coherent DMA API. When creating a new CB, the IOCTL returns a handle of it, and the user-space process needs to use that handle to mmap the buffer to get a VA in the user's address-space. Before destroying (freeing) a CB, the user must unmap the CB's VA using the CB handle. Each CB has a reference counter, which tracks its usage in command submissions and also its mmaps (only a single mmap is allowed). The driver maintains a pool of pre-allocated CBs in order to reduce latency during command submissions. In case the pool is empty, the driver will go to the slow-path of allocating a new CB, i.e. calling dma_alloc_coherent. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add context and ASID modulesOded Gabbay6-3/+374
This patch adds two modules - ASID and context. Each user process that opens a device's file must have at least one context before it is able to "work" with the device. Each context has its own device address-space and contains information about its runtime state (its active command submissions). To have address-space separation between contexts, each context is assigned a unique ASID, which stands for "address-space id". Goya supports up to 1024 ASIDs. Currently, the driver doesn't support multiple contexts. Therefore, the user doesn't need to actively create a context. A "primary context" is created automatically when the user opens the device's file. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add basic Goya supportOded Gabbay8-0/+1046
This patch adds a basic support for the Goya device. The code initializes the device's PCI controller and PCI bars. It also initializes various S/W structures and adds some basic helper functions. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add Goya registers header filesOded Gabbay94-0/+30555
This patch just adds a lot of header files that contain description of Goya's registers. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-18habanalabs: add skeleton driverOded Gabbay7-0/+860
This patch adds the habanalabs skeleton driver. The driver does nothing at this stage except very basic operations. It contains the minimal code to insmod and rmmod the driver and to create a /dev/hlX file per PCI device. Reviewed-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-14eeprom: at24: implement support for 'num-addresses' propertyBartosz Golaszewski1-5/+8
If the device node defines 'num-addresses', let it override the default behavior. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-02-14eeprom: at24: remove at24_platform_dataBartosz Golaszewski1-87/+75
There are no more users of at24_platform_data. Remove the relevant header and modify the driver code to not use it anymore. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2019-02-12misc: fastrpc: Add support for dmabuf exporterSrinivas Kandagatla1-0/+184
User process can involve dealing with big buffer sizes, and also passing buffers from one compute context bank to other compute context bank for complex dsp algorithms. This patch adds support to fastrpc to make it a proper dmabuf exporter to avoid making copies of buffers. Co-developed-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12misc: fastrpc: Add support for create remote init processSrinivas Kandagatla1-0/+156
This patch adds support to create or attach remote shell process. The shell process called fastrpc_shell_0 is usually loaded on the DSP when a user process is spawned. Most of the work is derived from various downstream Qualcomm kernels. Credits to various Qualcomm authors who have contributed to this code. Specially Tharun Kumar Merugu <mtharu@codeaurora.org> Co-developed-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12misc: fastrpc: Add support for context Invoke methodSrinivas Kandagatla1-0/+730
This patch adds support to compute context invoke method on the remote processor (DSP). This involves setting up the functions input and output arguments, input and output handles and mapping the dmabuf fd for the argument/handle buffers. The below diagram depicts invocation of a single method where the client and objects reside on different processors. An object could expose multiple methods which can be grouped together and referred to as an interface. ,--------, ,------, ,-----------, ,------, ,--------, | | method | | | | | | method | | | Client |------->| Stub |->| Transport |->| Skel |------->| Object | | | | | | | | | | | `--------` `------` `-----------` `------` `--------` Client: Linux user mode process that initiates the remote invocation Stub: Auto generated code linked in with the user mode process that takes care of marshaling parameters Transport: Involved in carrying an invocation from a client to an object. This involves two portions: 1) FastRPC Linux kernel driver that receives the remote invocation, queues them up and then waits for the response after signaling the remote side. 2) Service running on the remote side that dequeues the messages from the queue and dispatches them for processing. Skel: Auto generated code that takes care of un-marshaling parameters Object: Method implementation Most of the work is derived from various downstream Qualcomm kernels. Credits to various Qualcomm authors who have contributed to this code. Specially Tharun Kumar Merugu <mtharu@codeaurora.org> Co-developed-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12misc: fastrpc: Add Qualcomm fastrpc basic driver modelSrinivas Kandagatla3-0/+333
This patch adds basic driver model for Qualcomm FastRPC driver which implements an IPC (Inter-Processor Communication) mechanism that allows for clients to transparently make remote method invocations across processor boundaries. Each DSP rpmsg channel is represented as fastrpc channel context and is exposed as a character device for userspace interface. Each compute context bank is represented as fastrpc-session-context, which are dynamically managed by the channel context char device. Co-developed-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Thierry Escande <thierry.escande@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12vmw_balloon: release lock on error in vmballoon_reset()Dan Carpenter1-2/+3
We added some locking to this function but forgot to drop the lock on these two error paths. This bug would lead to an immediate deadlock. Fixes: c7b3690fb152 ("vmw_balloon: stats rework") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable@vger.kernel.org Reviewed-by: Nadav Amit <namit@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-12mei: bus: export to_mei_cl_device for mei client devices driversTomas Winkler1-1/+0
Export to_mei_cl_device macro, as it is needed also in the mei client drivers. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-11Merge 5.0-rc6 into char-misc-nextGreg Kroah-Hartman4-31/+51
We need the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-08vmw_balloon: support 64-bit memory limitXavier Deguillard1-3/+15
Currently, the balloon driver would fail to run if memory is greater than 16TB of vRAM. Previous patches have already converted the balloon target and size to 64-bit, so all that is left to do add is to avoid asserting memory is smaller than 16TB if the hypervisor supports 64-bits target. The driver advertises a new capability VMW_BALLOON_64_BITS_TARGET. Hypervisors that support 16TB of memory or more will report that this capability is enabled. Signed-off-by: Xavier Deguillard <xdeguillard@vmware.com> Signed-off-by: Nadav Amit <namit@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-08vmw_balloon: remove the version numberNadav Amit1-1/+0
Following the new kernel policy. Signed-off-by: Nadav Amit <namit@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-07drivers/mic/scif: do not use mmap_semDavidlohr Bueso1-25/+11
The driver uses mmap_sem for both pinned_vm accounting and get_user_pages(). By using gup_fast() and letting the mm handle the lock if needed, we can no longer rely on the semaphore and simplify the whole thing. Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-02-07mm: make mm->pinned_vm an atomic64 counterDavidlohr Bueso1-3/+3
Taking a sleeping lock to _only_ increment a variable is quite the overkill, and pretty much all users do this. Furthermore, some drivers (ie: infiniband and scif) that need pinned semantics can go to quite some trouble to actually delay via workqueue (un)accounting for pinned pages when not possible to acquire it. By making the counter atomic we no longer need to hold the mmap_sem and can simply some code around it for pinned_vm users. The counter is 64-bit such that we need not worry about overflows such as rdma user input controlled from userspace. Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Christoph Lameter <cl@linux.com> Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-02-01PCI: Move Rohm Vendor ID to generic listAndy Shevchenko1-1/+0
Move the Rohm Vendor ID to pci_ids.h instead of defining it in several drivers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2019-02-01mic: vop: Fix crash on removeVincent Whitchurch1-3/+6
The remove path contains a hack which depends on internal structures in other source files, similar to the one which was recently removed from the registration path. Since commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support"), this leads to a crash when vop devices are removed. The structure in question is only examined to get the virtual address of the allocated used page. Store that pointer locally instead to fix the crash. Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-01mic: vop: Fix use-after-free on removeVincent Whitchurch1-1/+3
KASAN detects a use-after-free when vop devices are removed. This problem was introduced by commit 0063e8bbd2b62d136 ("virtio_vop: don't kfree device on register failure"). That patch moved the freeing of the struct _vop_vdev to the release function, but failed to ensure that vop holds a reference to the device when it doesn't want it to go away. A kfree() was replaced with a put_device() in the unregistration path, but the last reference to the device is already dropped in unregister_virtio_device() so the struct is freed before vop is done with it. Fix it by holding a reference until cleanup is done. This is similar to the fix in virtio_pci in commit 2989be09a8a9d6 ("virtio_pci: fix use after free on release"). ================================================================== BUG: KASAN: use-after-free in vop_scan_devices+0xc6c/0xe50 [vop] Read of size 8 at addr ffff88800da18580 by task kworker/0:1/12 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc4+ #53 Workqueue: events vop_hotplug_devices [vop] Call Trace: dump_stack+0x74/0xbb print_address_description+0x5d/0x2b0 ? vop_scan_devices+0xc6c/0xe50 [vop] kasan_report+0x152/0x1aa ? vop_scan_devices+0xc6c/0xe50 [vop] ? vop_scan_devices+0xc6c/0xe50 [vop] vop_scan_devices+0xc6c/0xe50 [vop] ? vop_loopback_free_irq+0x160/0x160 [vop_loopback] process_one_work+0x7c0/0x14b0 ? pwq_dec_nr_in_flight+0x2d0/0x2d0 ? do_raw_spin_lock+0x120/0x280 worker_thread+0x8f/0xbf0 ? __kthread_parkme+0x78/0xf0 ? process_one_work+0x14b0/0x14b0 kthread+0x2ae/0x3a0 ? kthread_park+0x120/0x120 ret_from_fork+0x3a/0x50 Allocated by task 12: kmem_cache_alloc_trace+0x13a/0x2a0 vop_scan_devices+0x473/0xe50 [vop] process_one_work+0x7c0/0x14b0 worker_thread+0x8f/0xbf0 kthread+0x2ae/0x3a0 ret_from_fork+0x3a/0x50 Freed by task 12: kfree+0x104/0x310 device_release+0x73/0x1d0 kobject_put+0x14f/0x420 unregister_virtio_device+0x32/0x50 vop_scan_devices+0x19d/0xe50 [vop] process_one_work+0x7c0/0x14b0 worker_thread+0x8f/0xbf0 kthread+0x2ae/0x3a0 ret_from_fork+0x3a/0x50 The buggy address belongs to the object at ffff88800da18008 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1400 bytes inside of 2048-byte region [ffff88800da18008, ffff88800da18808) The buggy address belongs to the page: page:ffffea0000368600 count:1 mapcount:0 mapping:ffff88801440dbc0 index:0x0 compound_mapcount: 0 flags: 0x4000000000010200(slab|head) raw: 4000000000010200 ffffea0000378608 ffffea000037a008 ffff88801440dbc0 raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800da18480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800da18500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88800da18580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800da18600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800da18680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 0063e8bbd2b62d136 ("virtio_vop: don't kfree device on register failure") Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30mic: vop: Fix broken virtqueuesVincent Whitchurch1-26/+34
VOP is broken in mainline since commit 1ce9e6055fa0a9043 ("virtio_ring: introduce packed ring support"); attempting to use the virtqueues leads to various kernel crashes. I'm testing it with my not-yet-merged loopback patches, but even the in-tree MIC hardware cannot work. The problem is not in the referenced commit per se, but is due to the following hack in vop_find_vq() which depends on the layout of private structures in other source files, which that commit happened to change: /* * To reassign the used ring here we are directly accessing * struct vring_virtqueue which is a private data structure * in virtio_ring.c. At the minimum, a BUILD_BUG_ON() in * vring_new_virtqueue() would ensure that * (&vq->vring == (struct vring *) (&vq->vq + 1)); */ vr = (struct vring *)(vq + 1); vr->used = used; Fix vop by using __vring_new_virtqueue() to create the needed vring layout from the start, instead of attempting to patch in the used ring later. __vring_new_virtqueue() was added way back in commit 2a2d1382fe9dcc ("virtio: Add improved queue allocation API") in order to address mic's usecase, according to the commit message. Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30mei: free read cb on ctrl_wr list flushAlexander Usyskin1-1/+4
There is a little window during disconnection flow when read cb is moved between lists and may be not freed. Remove moving read cbs explicitly during flash fixes this memory leak. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30mei: me: add ice lake point device id.Tomas Winkler2-0/+4
Add icelake mei device id. Cc: <stable@vger.kernel.org> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-30cxl: Wrap iterations over afu slices inside 'afu_list_lock'Vaibhav Jain2-9/+32
Within cxl module, iteration over array 'adapter->afu' may be racy at few points as it might be simultaneously read during an EEH and its contents being set to NULL while driver is being unloaded or unbound from the adapter. This might result in a NULL pointer to 'struct afu' being de-referenced during an EEH thereby causing a kernel oops. This patch fixes this by making sure that all access to the array 'adapter->afu' is wrapped within the context of spin-lock 'adapter->afu_list_lock'. Fixes: 9e8df8a21963 ("cxl: EEH support") Cc: stable@vger.kernel.org # v4.3+ Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com> Acked-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>