summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* crypto: user - Add CRYPTO_MSG_DELRNGHerbert Xu2015-06-222-1/+12
| | | | | | | | | This patch adds a new crypto_user command that allows the admin to delete the crypto system RNG. Note that this can only be done if the RNG is currently not in use. The next time it is used a new system RNG will be allocated. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: user - Move cryptouser.h to uapiHerbert Xu2015-06-221-0/+0
| | | | | | | The header file cryptouser.h only contains information that is exported to user-space. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: rng - Do not free default RNG when it becomes unusedHerbert Xu2015-06-222-4/+32
| | | | | | | | | | | | | | | | | Currently we free the default RNG when its use count hits zero. This was OK when the IV generators would latch onto the RNG at instance creation time and keep it until the instance is torn down. Now that IV generators only keep the RNG reference during init time this scheme causes the default RNG to come and go at a high frequencey. This is highly undesirable as we want to keep a single RNG in use unless the admin wants it to be removed. This patch changes the scheme so that the system RNG once allocated is never removed unless a specifically requested. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: skcipher - Allow givencrypt to be NULLHerbert Xu2015-06-221-1/+1
| | | | | | | | | | | | | | | Currently for skcipher IV generators they must provide givencrypt as that is the whole point. We are currently replacing skcipher IV generators with explicit IV generators. In order to maintain backwards compatibility, we need to allow the IV generators to still function as a normal skcipher when the RNG Is not present (e.g., in the initramfs during boot). IOW everything but givencrypt and givdecrypt will still work but those two will fail. Therefore this patch assigns a default givencrypt that simply returns an error should it be NULL. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: sahara - propagate the error on clk_disable_unprepare() failureFabio Estevam2015-06-211-4/+9
| | | | | | | | clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: rsa - fix invalid select for AKCIPHERTadeusz Struk2015-06-211-1/+1
| | | | | | | | Should be CRYPTO_AKCIPHER instead of AKCIPHER Reported-by: Andreas Ruprecht <andreas.ruprecht@fau.de> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: picoxcell - Update to the current clk APIMichael van der Westhuizen2015-06-211-4/+4
| | | | | | | | | | | The picoXcell hardware crypto accelerator driver was using an older version of the clk framework, and not (un)preparing the clock before enabling/disabling it. This change uses the handy clk_prepare_enable function to interact with the current clk framework correctly. Signed-off-by: Michael van der Westhuizen <michael@smart-africa.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: nx - Check for bogus firmware propertiesHerbert Xu2015-06-211-32/+118
| | | | | | | | | | | | | | | | | The nx driver reads two crucial paramters from the firmware for each crypto algorithm, the maximum SG list length and byte limit. Unfortunately those two parameters may be bogus, or worse they may be absent altogether. When this happens the algorithms will still register successfully but will fail when used or tested. This patch adds checks to report any firmware entries which are found to be bogus, and avoid registering algorithms which have bogus parameters. A warning is also printed when an algorithm is not registered because of this as there may have been no firmware entries for it at all. Reported-by: Ondrej Moriš <omoris@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add DT bindings documentationBoris BREZILLON2015-06-191-0/+45
| | | | | | | Add DT bindings documentation for the new marvell-cesa driver. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add support for Kirkwood and Dove SoCsArnaud Ebalard2015-06-191-1/+12
| | | | | | | | | | Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport module parameter to avoid probing the CESA IP when the old CESA driver is enabled (unless it is explicitly requested to do so). Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add support for Orion SoCsBoris BREZILLON2015-06-191-7/+35
| | | | | | | | | | | | | Add the Orion SoC description, and select this implementation by default to support non-DT probing: Orion is the only platform where non-DT boards are declaring the CESA block. Control the allhwsupport module parameter to avoid probing the CESA IP when the old CESA driver is enabled (unless it is explicitly requested to do so). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add allhwsupport module parameterBoris BREZILLON2015-06-191-0/+4
| | | | | | | | | | | | The old and new marvell CESA drivers both support Orion and Kirkwood SoCs. Add a module parameter to choose whether these SoCs should be attached to the new or the old driver. The default policy is to keep attaching those IPs to the old driver if it is enabled, until we decide the new CESA driver is stable/secure enough. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add support for all armada SoCsBoris BREZILLON2015-06-191-0/+12
| | | | | | | Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x). Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add SHA256 supportArnaud Ebalard2015-06-193-0/+163
| | | | | | | | Add support for SHA256 operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add MD5 supportArnaud Ebalard2015-06-193-2/+174
| | | | | | | | Add support for MD5 operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add Triple-DES supportArnaud Ebalard2015-06-193-0/+151
| | | | | | | | Add support for Triple-DES operations. Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add DES supportBoris BREZILLON2015-06-193-0/+154
| | | | | | | | Add support for DES operations. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add TDMA supportBoris BREZILLON2015-06-197-16/+1101
| | | | | | | | | | | | | | | | | | The CESA IP supports CPU offload through a dedicated DMA engine (TDMA) which can control the crypto block. When you use this mode, all the required data (operation metadata and payload data) are transferred using DMA, and the results are retrieved through DMA when possible (hash results are not retrieved through DMA yet), thus reducing the involvement of the CPU and providing better performances in most cases (for small requests, the cost of DMA preparation might exceed the performance gain). Note that some CESA IPs do not embed this dedicated DMA, hence the activation of this feature on a per platform basis. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: marvell/cesa - add a new driver for Marvell's CESABoris BREZILLON2015-06-197-0/+2040
| | | | | | | | | | | | | | | | | | | The existing mv_cesa driver supports some features of the CESA IP but is quite limited, and reworking it to support new features (like involving the TDMA engine to offload the CPU) is almost impossible. This driver has been rewritten from scratch to take those new features into account. This commit introduce the base infrastructure allowing us to add support for DMA optimization. It also includes support for one hash (SHA1) and one cipher (AES) algorithm, and enable those features on the Armada 370 SoC. Other algorithms and platforms will be added later on. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: mv_cesa - explicitly define kirkwood and dove compatible stringsBoris BREZILLON2015-06-192-2/+7
| | | | | | | | | | | | | | | | | We are about to add a new driver to support new features like using the TDMA engine to offload the CPU. Orion, Dove and Kirkwood platforms are already using the mv_cesa driver, but Orion SoCs do not embed the TDMA engine, which means we will have to differentiate them if we want to get TDMA support on Dove and Kirkwood. In the other hand, the migration from the old driver to the new one is not something all people are willing to do without first auditing the new driver. Hence we have to support the new compatible in the mv_cesa driver so that new platforms with updated DTs can still attach their crypto engine device to this driver. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: mv_cesa - use gen_pool to reserve the SRAM memory regionBoris BREZILLON2015-06-193-23/+60
| | | | | | | | | | | | | | | | | | | | | | | The mv_cesa driver currently expects the SRAM memory region to be passed as a platform device resource. This approach implies two drawbacks: - the DT representation is wrong - the only one that can access the SRAM is the crypto engine The last point is particularly annoying in some cases: for example on armada 370, a small region of the crypto SRAM is used to implement the cpuidle, which means you would not be able to enable both cpuidle and the CESA driver. To address that problem, we explicitly define the SRAM device in the DT and then reference the sram node from the crypto engine node. Also note that the old way of retrieving the SRAM memory region is still supported, or in other words, backward compatibility is preserved. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: mv_cesa - document the clocks propertyBoris BREZILLON2015-06-191-0/+2
| | | | | | | | On Dove platforms, the crypto engine requires a clock. Document this clocks property in the mv_cesa bindings doc. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* Merge branch 'mvebu/drivers' of ↵Herbert Xu2015-06-194373-96023/+172587
|\ | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Merge the mvebu/drivers branch of the arm-soc tree which contains just a single patch bfa1ce5f38938cc9e6c7f2d1011f88eba2b9e2b2 ("bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()") that happens to be a prerequisite of the new marvell/cesa crypto driver.
| * bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap()Thomas Petazzoni2015-05-282-0/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a variant of the mv_mbus_dram_info() function called mv_mbus_dram_info_nooverlap(). Both functions are used by Marvell drivers supporting devices doing DMA, and provide them a description the DRAM ranges that they need to configure their DRAM windows. The ranges provided by the mv_mbus_dram_info() function may overlap with the I/O windows if there is a lot (>= 4 GB) of RAM installed. This is not a problem for most of the DMA masters, except for the upcoming new CESA crypto driver because it does DMA to the SRAM, which is mapped through an I/O window. For this unit, we need to have DRAM ranges that do not overlap with the I/O windows. A first implementation done in commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"), changed the information returned by mv_mbus_dram_info() to match this requirement. However, it broke the requirement of the other DMA masters than the DRAM ranges should have power of two sizes. To solve this situation, this commit introduces a new mv_mbus_dram_info_nooverlap() function, which returns the same information as mv_mbus_dram_info(), but guaranteed to not overlap with the I/O windows. In the end, it gives us two variants of the mv_mbus_dram_info*() functions: - The normal one, mv_mbus_dram_info(), which has been around for many years. This function returns the raw DRAM ranges, which are guaranteed to use power of two sizes, but will overlap with I/O windows. This function will therefore be used by all DMA masters (SATA, XOR, Ethernet, etc.) except the CESA crypto driver. - The new 'nooverlap' variant, mv_mbus_dram_info_nooverlap(). This function returns DRAM ranges after they have been "tweaked" to make sure they don't overlap with I/O windows. By doing this tweaking, we remove the power of two size guarantee. This variant will be used by the new CESA crypto driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
| * Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus ↵Thomas Petazzoni2015-05-281-89/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bridge window" This reverts commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"), because it breaks DMA on platforms having more than 2 GB of RAM. This commit changed the information reported to DMA masters device drivers through the mv_mbus_dram_info() function so that the returned DRAM ranges do not overlap with I/O windows. This was necessary as a preparation to support the new CESA Crypto Engine driver, which will use DMA for cryptographic operations. But since it does DMA with the SRAM which is mapped as an I/O window, having DRAM ranges overlapping with I/O windows was problematic. To solve this, the above mentioned commit changed the mvebu-mbus to adjust the DRAM ranges so that they don't overlap with the I/O windows. However, by doing this, we re-adjust the DRAM ranges in a way that makes them have a size that is no longer a power of two. While this is perfectly fine for the Crypto Engine, which supports DRAM ranges with a granularity of 64 KB, it breaks basically all other DMA masters, which expect power of two sizes for the DRAM ranges. Due to this, if the installed system memory is 4 GB, in two chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB to a little bit less than 2 GB to not overlap with the I/O windows, in a way that results in a DRAM range that doesn't have a power of two size. This means that whenever you do a DMA transfer with an address located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any serious DMA activity like simply running: for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done in an ext3 partition mounted over a SATA drive will freeze the system. Since the new CESA crypto driver that uses DMA has not been merged yet, the easiest fix is to simply revert this commit. A follow-up commit will introduce a different solution for the CESA crypto driver. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Fixes: 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window") Cc: <stable@vger.kernel.org> # v4.0+ Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
| * bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.Nicolas Schichan2015-05-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") enabled the usage of automatic I/O synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the control registers of MBus windows, but on non io-coherent platforms (orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in the window control register is either reserved (all windows except 6 and 7) or enables read-only protection (windows 6 and 7). Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v4.0+ Fixes: a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
| * ARM: mvebu: armada-xp-linksys-mamba: Disable internal RTCImre Kaloz2015-05-281-0/+5
| | | | | | | | | | | | | | | | | | | | The Mamba (like the OpenBlocks AX3) doesn't have a crystal connected to the internal RTC - let's prevent the kernel from probing it. Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Cc: <stable@vger.kernel.org> # v4.0 + Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
| * MAINTAINERS: Add dts entries for some of the Marvell SoCsGregory CLEMENT2015-05-151-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since many releases, the modifications of the mvebu and berlin device tree files are merged through the mvebu subsystem. This patch makes it official in order to help the contributors using the get_maintainer.pl to find the accurate peoples. In the same time, updated the mvebu description which now includes the kirkwood SoCs and new Armada SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Andrew Lunn <andrew@lunn.ch>
| * ARM: dove: Add clock-names to CuBox Si5351 clk generatorSebastian Hesselbarth2015-05-111-0/+1
| | | | | | | | | | | | | | Si5351 clock generator on CuBox uses XTAL as clock reference, name the clock phandle accordingly. Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
| * ARM: mvebu: Fix the main PLL frequency on Armada 375, 38x and 39x SoCsGregory CLEMENT2015-05-013-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whereas for Armada 370 and XP the main PLL frequency was 2GHz for the Armada 375, 38x and 39x, the frequency is 1GHz. When writing support for these last SoCs, there was no official value for the PLL. Now that we have it, this patch fixes it in the device tree. This value is currently only used by the NAND driver for the setting the NAND timing. Fortunately it is not actually used: all the mainline board with a NAND flash comes with a NAND device tree node using the "marvell,nand-keep-config" property. With this property the timings are not modified in the kernel driver and are kept from the bootloader. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Marcin Wojtas <mw@semihalf.com>
| * ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTCGregory CLEMENT2015-04-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.8 +
| * Linux 4.1-rc1v4.1-rc1Linus Torvalds2015-04-271-2/+2
| |
| * x86_64, asm: Work around AMD SYSRET SS descriptor attribute issueAndy Lutomirski2015-04-275-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AMD CPUs don't reinitialize the SS descriptor on SYSRET, so SYSRET with SS == 0 results in an invalid usermode state in which SS is apparently equal to __USER_DS but causes #SS if used. Work around the issue by setting SS to __KERNEL_DS __switch_to, thus ensuring that SYSRET never happens with SS set to NULL. This was exposed by a recent vDSO cleanup. Fixes: e7d6eefaaa44 x86/vdso32/syscall.S: Do not load __USER32_DS to %ss Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Peter Anvin <hpa@zytor.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <vda.linux@googlemail.com> Cc: Brian Gerst <brgerst@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2015-04-275-14/+95
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Pull intel drm fixes from Dave Airlie. * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg drm/i915: Workaround to avoid lite restore with HEAD==TAIL drm/i915: cope with large i2c transfers
| | * Merge tag 'drm-intel-next-fixes-2015-04-25' of ↵Dave Airlie2015-04-275-14/+95
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-fixes three fixes for i915. * tag 'drm-intel-next-fixes-2015-04-25' of git://anongit.freedesktop.org/drm-intel: drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg drm/i915: Workaround to avoid lite restore with HEAD==TAIL drm/i915: cope with large i2c transfers
| | | * drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT regImre Deak2015-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | | * drm/i915: Workaround to avoid lite restore with HEAD==TAILMichel Thierry2015-04-232-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WaIdleLiteRestore is an execlists-only workaround, and requires the driver to ensure that any context always has HEAD!=TAIL when attempting lite restore. Add two extra MI_NOOP instructions at the end of each request, but keep the requests tail pointing before the MI_NOOPs. We may not need to executed them, and this is why request->tail is sampled before adding these extra instructions. If we submit a context to the ELSP which has previously been submitted, move the tail pointer past the MI_NOOPs. This ensures HEAD!=TAIL. v2: Move overallocation to gen8_emit_request, and added note about sampling request->tail in commit message (Chris). v3: Remove redundant request->tail assignment in __i915_add_request, in lrc mode this is already set in execlists_context_queue. Do not add wa implementation details inside gem (Chris). v4: Apply the wa whenever the req has been resubmitted and update comment (Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | | * drm/i915: cope with large i2c transfersDmitry Torokhov2015-04-232-10/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | Merge git://git.infradead.org/intel-iommuLinus Torvalds2015-04-273-83/+82
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull intel iommu updates from David Woodhouse: "This lays a little of the groundwork for upcoming Shared Virtual Memory support — fixing some bogus #defines for capability bits and adding the new ones, and starting to use the new wider page tables where we can, in anticipation of actually filling in the new fields therein. It also allows graphics devices to be assigned to VM guests again. This got broken in 3.17 by disallowing assignment of RMRR-afflicted devices. Like USB, we do understand why there's an RMRR for graphics devices — and unlike USB, it's actually sane. So we can make an exception for graphics devices, just as we do USB controllers. Finally, tone down the warning about the X2APIC_OPT_OUT bit, due to persistent requests. X2APIC_OPT_OUT was added to the spec as a nasty hack to allow broken BIOSes to forbid us from using X2APIC when they do stupid and invasive things and would break if we did. Someone noticed that since Windows doesn't have full IOMMU support for DMA protection, setting the X2APIC_OPT_OUT bit made Windows avoid initialising the IOMMU on the graphics unit altogether. This means that it would be available for use in "driver mode", where the IOMMU registers are made available through a BAR of the graphics device and the graphics driver can do SVM all for itself. So they started setting the X2APIC_OPT_OUT bit on *all* platforms with SVM capabilities. And even the platforms which *might*, if the planets had been aligned correctly, possibly have had SVM capability but which in practice actually don't" * git://git.infradead.org/intel-iommu: iommu/vt-d: support extended root and context entries iommu/vt-d: Add new extended capabilities from v2.3 VT-d specification iommu/vt-d: Allow RMRR on graphics devices too iommu/vt-d: Print x2apic opt out info instead of printing a warning iommu/vt-d: kill bogus ecap_niotlb_iunits()
| | * | | iommu/vt-d: support extended root and context entriesDavid Woodhouse2015-03-251-75/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new function iommu_context_addr() which takes care of the differences and returns a pointer to a context entry which may be in either format. The formats are binary compatible for all the old fields anyway; the new one is just larger and some of the reserved bits in the original 128 are now meaningful. So far, nothing actually uses the new fields in the extended context entry. Modulo hardware bugs with interpreting the new-style tables, this should basically be a no-op. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| | * | | iommu/vt-d: Add new extended capabilities from v2.3 VT-d specificationDavid Woodhouse2015-03-251-0/+14
| | | | | | | | | | | | | | | | | | | | Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| | * | | iommu/vt-d: Allow RMRR on graphics devices tooDavid Woodhouse2015-03-251-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains") prevents certain options for devices with RMRRs. This even prevents those devices from getting a 1:1 mapping with 'iommu=pt', because we don't have the code to handle *preserving* the RMRR regions when moving the device between domains. There's already an exclusion for USB devices, because we know the only reason for RMRRs there is a misguided desire to keep legacy keyboard/mouse emulation running in some theoretical OS which doesn't have support for USB in its own right... but which *does* enable the IOMMU. Add an exclusion for graphics devices too, so that 'iommu=pt' works there. We should be able to successfully assign graphics devices to guests too, as long as the initial handling of stolen memory is reconfigured appropriately. This has certainly worked in the past. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org
| | * | | iommu/vt-d: Print x2apic opt out info instead of printing a warningFenghua Yu2015-03-251-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BIOS can set up x2apic_opt_out bit on some platforms, for various misguided reasons like insane SMM code with weird assumptions about what descriptors look like, or wanting Windows not to enable the IOMMU so that the graphics driver will take it over for SVM in "driver mode". A user can either disable the x2apic_opt_out bit in BIOS or by kernel parameter "no_x2apic_optout". Instead of printing a warning, we just print information of x2apic opt out. Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| | * | | iommu/vt-d: kill bogus ecap_niotlb_iunits()David Woodhouse2015-03-251-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far back as I can see (which right now is a draft of the v1.2 spec dating from September 2008), bits 24-31 of the Extended Capability Register have already been reserved. I have no idea why anyone ever thought there would be multiple sets of IOTLB registers, but we've never supported them and all we do is make sure we map enough MMIO space for them. Kill it dead. Those bits do actually have a different meaning now. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
| * | | | Merge branch 'i2c/for-next' of ↵Linus Torvalds2015-04-277-14/+18
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "This has a mixture of merge window cleanups and bugfixes" * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: st: add include for pinctrl i2c: mux: use proper dev when removing "channel-X" symlinks i2c: digicolor: remove duplicate include i2c: Mark adapter devices with pm_runtime_no_callbacks i2c: pca-platform: fix broken email address i2c: mxs: fix broken email address i2c: rk3x: report number of messages transmitted
| | * | | | i2c: st: add include for pinctrlWolfram Sang2015-04-231-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver uses pinctrl directly and thus should include the appropriate header. Sort the headers while we are here to have a better view what is included and what is not. Reported-by: Pascal Huerst <pascal.huerst@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| | * | | | i2c: mux: use proper dev when removing "channel-X" symlinksWolfram Sang2015-04-231-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those symlinks are created for the mux_dev, so we need to remove it from there. Currently, it breaks for muxes where the mux_dev is not the device of the parent adapter like this: [ 78.234644] WARNING: CPU: 0 PID: 365 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x78() [ 78.242438] sysfs: cannot create duplicate filename '/devices/platform/i2cbus@8/channel-0' Remove confusing comments while we are here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: c9449affad2ae0 Cc: stable@kernel.org
| | * | | | i2c: digicolor: remove duplicate includeWolfram Sang2015-04-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And sort them to prevent this from happening again. Reported-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
| | * | | | i2c: Mark adapter devices with pm_runtime_no_callbacksCharles Keepax2015-04-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 523c5b89640e ("i2c: Remove support for legacy PM") removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Beata Michalska <b.michalska@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Fixes: 523c5b89640e Cc: stable@kernel.org
| | * | | | i2c: pca-platform: fix broken email addressWolfram Sang2015-04-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My Pengutronix address is not valid anymore, redirect people to the Pengutronix kernel team. Reported-by: Harald Geyer <harald@ccbib.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-04 00:26:51 +0100