summaryrefslogtreecommitdiffstats
path: root/drivers/iommu/arm-smmu.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* iommu/arm-smmu: Use accessor functions for iommu private dataJoerg Roedel2020-03-271-8/+9
| | | | | | | | | Make use of dev_iommu_priv_set/get() functions and simplify the code where possible with this change. Signed-off-by: Joerg Roedel <jroedel@suse.de> Tested-by: Will Deacon <will@kernel.org> # arm-smmu Link: https://lore.kernel.org/r/20200326150841.10083-12-joro@8bytes.org
* iommu/arm-smmu: Refactor master_cfg/fwspec usageRobin Murphy2020-03-271-20/+22
| | | | | | | | | | In preparation for restructuring iommu_fwspec, refactor the way we access the arm_smmu_master_cfg private data to be less dependent on the current layout. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200326150841.10083-11-joro@8bytes.org
* iommu/arm-smmu: Fix uninitilized variable warningJoerg Roedel2020-03-271-1/+1
| | | | | | | | | | | | | | | | | | | Some unrelated changes in the iommu code caused a new warning to appear in the arm-smmu driver: CC drivers/iommu/arm-smmu.o drivers/iommu/arm-smmu.c: In function 'arm_smmu_add_device': drivers/iommu/arm-smmu.c:1441:2: warning: 'smmu' may be used uninitialized in this function [-Wmaybe-uninitialized] arm_smmu_rpm_put(smmu); ^~~~~~~~~~~~~~~~~~~~~~ The warning is a false positive, but initialize the variable to NULL to get rid of it. Signed-off-by: Joerg Roedel <jroedel@suse.de> Tested-by: Will Deacon <will@kernel.org> # arm-smmu Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Link: https://lore.kernel.org/r/20200326150841.10083-8-joro@8bytes.org
*-. Merge branches 'iommu/fixes', 'arm/smmu', 'x86/amd', 'x86/vt-d' and 'core' ↵Joerg Roedel2020-01-241-136/+198
|\ \ | | | | | | | | | into next
| | * iommu: arm: Use generic_iommu_put_resv_regions()Thierry Reding2019-12-231-10/+1
| |/ |/| | | | | | | | | | | | | | | | | Use the new standard function instead of open-coding it. Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/arm-smmu: Improve SMR mask testRobin Murphy2020-01-101-5/+18
| | | | | | | | | | | | | | | | | | Make the SMR mask test more robust against SMR0 being live at probe time, which might happen once we start supporting firmware reservations for framebuffers and suchlike. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable-arm: Rationalise VTCR handlingWill Deacon2020-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 05a648cd2dd7 ("iommu/io-pgtable-arm: Rationalise TCR handling") reworked the way in which the TCR register value is returned from the io-pgtable code when targetting the Arm long-descriptor format, in preparation for allowing page-tables to target TTBR1. As it turns out, the new interface is a lot nicer to use, so do the same conversion for the VTCR register even though there is only a single base register for stage-2 translation. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/arm-smmu: Rename public #defines under ARM_SMMU_ namespaceWill Deacon2020-01-101-74/+83
| | | | | | | | | | | | | | | | | | | | Now that we have arm-smmu.h defining various SMMU constants, ensure that they are namespaced with the ARM_SMMU_ prefix in order to avoid conflicts with the CPU, such as the one we're currently bodging around with the TCR. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable-arm: Rationalise TCR handlingRobin Murphy2020-01-101-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although it's conceptually nice for the io_pgtable_cfg to provide a standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU looks exactly like an Arm CPU, and they all have various other TCR controls which io-pgtable can't be expected to understand. Thus since there is an expectation that drivers will have to add to the given TCR value anyway, let's strip it down to just the essentials that are directly relevant to io-pgtable's inner workings - namely the various sizes and the walk attributes. Tested-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [will: Add missing include of bitfield.h] Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/io-pgtable-arm: Rationalise TTBRn handlingRobin Murphy2020-01-101-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TTBR1 values have so far been redundant since no users implement any support for split address spaces. Crucially, though, one of the main reasons for wanting to do so is to be able to manage each half entirely independently, e.g. context-switching one set of mappings without disturbing the other. Thus it seems unlikely that tying two tables together in a single io_pgtable_cfg would ever be particularly desirable or useful. Streamline the configs to just a single conceptual TTBR value representing the allocated table. This paves the way for future users to support split address spaces by simply allocating a table and dealing with the detailed TTBRn logistics themselves. Tested-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> [will: Drop change to ttbr value] Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/arm-smmu: Fix -Wunused-const-variable warningMasahiro Yamada2020-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For ARCH=arm builds, OF is not necessarily enabled, that is, you can build this driver without CONFIG_OF. When CONFIG_OF is unset, of_match_ptr() is NULL, and arm_smmu_of_match is left orphan. Building it with W=1 emits a warning: drivers/iommu/arm-smmu.c:1904:34: warning: ‘arm_smmu_of_match’ defined but not used [-Wunused-const-variable=] static const struct of_device_id arm_smmu_of_match[] = { ^~~~~~~~~~~~~~~~~ There are two ways to fix this: - annotate arm_smmu_of_match with __maybe_unused (or surround the code with #ifdef CONFIG_OF ... #endif) - stop using of_match_ptr() This commit took the latter solution. It slightly increases the object size, but it is probably not a big deal because arm_smmu_device_dt_probe() is also compiled irrespective of CONFIG_OF. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will@kernel.org>
| * drivers/iommu: Initialise module 'owner' field in iommu_device_set_ops()Will Deacon2020-01-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | Requiring each IOMMU driver to initialise the 'owner' field of their 'struct iommu_ops' is error-prone and easily forgotten. Follow the example set by PCI and USB by assigning THIS_MODULE automatically when registering the ops structure with IOMMU core. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Will Deacon <will@kernel.org>
| * iommu/arm-smmu: Update my email address in MODULE_AUTHOR()Will Deacon2019-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | I no longer work for Arm, so update the stale reference to my old email address. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/arm-smmu: Allow building as a moduleWill Deacon2019-12-231-20/+32
| | | | | | | | | | | | | | | | | | | | | | By conditionally dropping support for the legacy binding and exporting the newly introduced 'arm_smmu_impl_init()' function we can allow the ARM SMMU driver to be built as a module. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/arm-smmu: Unregister IOMMU and bus ops on device removalWill Deacon2019-12-231-10/+40
| | | | | | | | | | | | | | | | | | | | | | When removing the SMMU driver, we need to clear any state that we registered during probe. This includes our bus ops, sysfs entries and the IOMMU device registered for early firmware probing of masters. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/arm-smmu: Support SMMU module probing from the IORTArd Biesheuvel2019-12-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for SMMU drivers built as modules to the ACPI/IORT device probing path, by deferring the probe of the master if the SMMU driver is known to exist but has not been loaded yet. Given that the IORT code registers a platform device for each SMMU that it discovers, we can easily trigger the udev based autoloading of the SMMU drivers by making the platform device identifier part of the module alias. Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: John Garry <john.garry@huawei.com> # only manual smmu ko loading Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * iommu/arm-smmu: Prevent forced unbinding of Arm SMMU driversWill Deacon2019-12-231-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation, since it will likely lead to catastrophic failure for any DMA devices mastering through the SMMU being unbound. When the driver then attempts to "handle" the fatal faults, it's very easy to trip over dead data structures, leading to use-after-free. On John's machine, he reports that the machine was "unusable" due to loss of the storage controller following a forced unbind of the SMMUv3 driver: | # cd ./bus/platform/drivers/arm-smmu-v3 | # echo arm-smmu-v3.0.auto > unbind | hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found! | platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000146 | [hwprod 0x00000146, hwcons 0x00000000] Prevent this forced unbinding of the drivers by setting "suppress_bind_attrs" to true. Link: https://lore.kernel.org/lkml/06dfd385-1af0-3106-4cc5-6a5b8e864759@huawei.com Reported-by: John Garry <john.garry@huawei.com> Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| * Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"Will Deacon2019-12-231-13/+19
|/ | | | | | | | | | | | This reverts commit addb672f200f4e99368270da205320b83efe01a0. Let's get the SMMU driver building as a module, which means putting back some dead code that we used to carry. Signed-off-by: Will Deacon <will@kernel.org> Tested-by: John Garry <john.garry@huawei.com> # smmu v3 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
*---. Merge branches 'iommu/fixes', 'arm/qcom', 'arm/renesas', 'arm/rockchip', ↵Joerg Roedel2019-11-121-96/+127
|\ \ \ | | | | | | | | | | | | 'arm/mediatek', 'arm/tegra', 'arm/smmu', 'x86/amd', 'x86/vt-d', 'virtio' and 'core' into next
| | | * iommu: Add gfp parameter to iommu_ops::mapTom Murphy2019-10-151-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a gfp_t parameter to the iommu_ops::map function. Remove the needless locking in the AMD iommu driver. The iommu_ops::map function (or the iommu_map function which calls it) was always supposed to be sleepable (according to Joerg's comment in this thread: https://lore.kernel.org/patchwork/patch/977520/ ) and so should probably have had a "might_sleep()" since it was written. However currently the dma-iommu api can call iommu_map in an atomic context, which it shouldn't do. This doesn't cause any problems because any iommu driver which uses the dma-iommu api uses gfp_atomic in it's iommu_ops::map function. But doing this wastes the memory allocators atomic pools. Signed-off-by: Tom Murphy <murphyt7@tcd.ie> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| | * iommu/arm-smmu: Remove duplicate error messageJean-Philippe Brucker2019-11-111-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()"), platform_get_irq() displays an error when the IRQ isn't found. Remove the error print from the SMMU driver. Note the slight change of behaviour: no message is printed if platform_get_irq() returns -EPROBE_DEFER, which probably doesn't concern the SMMU. Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
| | * iommu/io-pgtable-arm: Rationalise MAIR handlingRobin Murphy2019-11-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Between VMSAv8-64 and the various 32-bit formats, there is either one 64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or NMRR/PMRR registers. As such, keeping two 64-bit values in io_pgtable_cfg has always been overkill. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| | * Merge branch 'for-joerg/arm-smmu/fixes' into for-joerg/arm-smmu/updatesWill Deacon2019-11-041-0/+1
| | |\ | |_|/ |/| | | | | | | | | | | | | | | | | | | | Merge in ARM SMMU fixes to avoid conflicts in the ARM io-pgtable code. * for-joerg/arm-smmu/fixes: iommu/io-pgtable-arm: Support all Mali configurations iommu/io-pgtable-arm: Correct Mali attributes iommu/arm-smmu: Free context bitmap in the err path of arm_smmu_init_domain_context
| | * iommu/arm-smmu: Avoid pathological RPM behaviour for unmapsRob Clark2019-11-011-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When games, browser, or anything using a lot of GPU buffers exits, there can be many hundreds or thousands of buffers to unmap and free. If the GPU is otherwise suspended, this can cause arm-smmu to resume/suspend for each buffer, resulting 5-10 seconds worth of reprogramming the context bank (arm_smmu_write_context_bank()/arm_smmu_write_s2cr()/etc). To the user it would appear that the system just locked up. A simple solution is to use pm_runtime_put_autosuspend() instead, so we don't immediately suspend the SMMU device. Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Axe a useless test in 'arm_smmu_master_alloc_smes()'Christophe JAILLET2019-10-011-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | 'iommu_group_get_for_dev()' never returns NULL, so this test can be removed. Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Report USF more clearlyRobin Murphy2019-10-011-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool for smoking out inadequate firmware, the failure mode is non-obvious and can be confusing for end users. Add some special-case reporting of Unidentified Stream Faults to help clarify this particular symptom. Since we're adding yet another print to the mix, also break out an explicit ratelimit state to make sure everything stays together (and reduce the static storage footprint a little). Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Remove arm_smmu_flush_opsRobin Murphy2019-10-011-23/+17
| | | | | | | | | | | | | | | | | | | | | Now it's just an empty wrapper. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Move .tlb_sync method to implementationRobin Murphy2019-10-011-18/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the .tlb_sync interface no longer exposed directly to io-pgtable, strip away the remains of that abstraction layer. Retain the callback in spirit, though, by transforming it into an implementation override for the low-level sync routine itself, for which we will have at least one user. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Remove "leaf" indirectionRobin Murphy2019-10-011-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the "leaf" flag is no longer part of an external interface, there's no need to use it to infer a register offset at runtime when we can just as easily encode the offset directly in its place. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
| | * iommu/arm-smmu: Remove .tlb_inv_range indirectionRobin Murphy2019-10-011-45/+61
| |/ | | | | | | | | | | | | | | | | Fill in 'native' iommu_flush_ops callbacks for all the arm_smmu_flush_ops variants, and clear up the remains of the previous .tlb_inv_range abstraction. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* / iommu/arm-smmu: Free context bitmap in the err path of ↵Liu Xiang2019-10-011-0/+1
|/ | | | | | | | | | arm_smmu_init_domain_context When alloc_io_pgtable_ops is failed, context bitmap which is just allocated by __arm_smmu_alloc_bitmap should be freed to release the resource. Signed-off-by: Liu Xiang <liuxiang_1999@126.com> Signed-off-by: Will Deacon <will@kernel.org>
* Merge tag 'devicetree-for-5.4' of ↵Linus Torvalds2019-09-191-1/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux Pull Devicetree updates from Rob Herring: - a bunch of DT binding conversions to DT schema format - clean-ups of the Arm idle-states binding - support a default number of cells in of_for_each_phandle() when the cells name is missing - expose dtbs_check and dt_binding_check in the make help - convert writting-schema.md to ReST - HiSilicon reset controller binding updates - add documentation for MT8516 RNG * tag 'devicetree-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (46 commits) of: restore old handling of cells_name=NULL in of_*_phandle_with_args() bus: qcom: fix spelling mistake "ambigous" -> "ambiguous" of: Let of_for_each_phandle fallback to non-negative cell_count iommu: pass cell_count = -1 to of_for_each_phandle with cells_name dt-bindings: arm: Convert Realtek board/soc bindings to json-schema dt-bindings: arm: Convert Actions Semi bindings to jsonschema dt-bindings: Correct spelling in example schema dt-bindings: cpu: Add a support cpu type for cortex-a55 dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible dt-bindings: arm: idle-states: Move exit-latency-us explanation dt-bindings: arm: idle-states: Add punctuation to improve readability dt-bindings: arm: idle-states: Correct "constraint guarantees" dt-bindings: arm: idle-states: Correct references to wake-up delay dt-bindings: arm: idle-states: Use "e.g." and "i.e." consistently pinctrl-mcp23s08: Fix property-name in dt-example dt-bindings: Clarify interrupts-extended usage dt-bindings: Convert Arm Mali Utgard GPU to DT schema dt-bindings: Convert Arm Mali Bifrost GPU to DT schema dt-bindings: Convert Arm Mali Midgard GPU to DT schema dt-bindings: irq: Convert Allwinner NMI Controller to a schema ...
| * iommu: pass cell_count = -1 to of_for_each_phandle with cells_nameUwe Kleine-König2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently of_for_each_phandle ignores the cell_count parameter when a cells_name is given. I intend to change that and let the iterator fall back to a non-negative cell_count if the cells_name property is missing in the referenced node. To not change how existing of_for_each_phandle's users iterate, fix them to pass cell_count = -1 when also cells_name is given which yields the expected behaviour with and without my change. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Rob Herring <robh@kernel.org>
* | Merge tag 'leds-for-5.4-rc1' of ↵Linus Torvalds2019-09-181-7/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: "In this cycle we've finally managed to contribute the patch set sorting out LED naming issues. Besides that there are many changes scattered among various LED class drivers and triggers. LED naming related improvements: - add new 'function' and 'color' fwnode properties and deprecate 'label' property which has been frequently abused for conveying vendor specific names that have been available in sysfs anyway - introduce a set of standard LED_FUNCTION* definitions - introduce a set of standard LED_COLOR_ID* definitions - add a new {devm_}led_classdev_register_ext() API with the capability of automatic LED name composition basing on the properties available in the passed fwnode; the function is backwards compatible in a sense that it uses 'label' data, if present in the fwnode, for creating LED name - add tools/leds/get_led_device_info.sh script for retrieving LED vendor, product and bus names, if applicable; it also performs basic validation of an LED name - update following drivers and their DT bindings to use the new LED registration API: - leds-an30259a, leds-gpio, leds-as3645a, leds-aat1290, leds-cr0014114, leds-lm3601x, leds-lm3692x, leds-lp8860, leds-lt3593, leds-sc27xx-blt Other LED class improvements: - replace {devm_}led_classdev_register() macros with inlines - allow to call led_classdev_unregister() unconditionally - switch to use fwnode instead of be stuck with OF one LED triggers improvements: - led-triggers: - fix dereferencing of null pointer - fix a memory leak bug - ledtrig-gpio: - GPIO 0 is valid Drop superseeded apu2/3 support from leds-apu since for apu2+ a newer, more complete driver exists, based on a generic driver for the AMD SOCs gpio-controller, supporting LEDs as well other devices: - drop profile field from priv data - drop iosize field from priv data - drop enum_apu_led_platform_types - drop superseeded apu2/3 led support - add pr_fmt prefix for better log output - fix error message on probing failure Other misc fixes and improvements to existing LED class drivers: - leds-ns2, leds-max77650: - add of_node_put() before return - leds-pwm, leds-is31fl32xx: - use struct_size() helper - leds-lm3697, leds-lm36274, leds-lm3532: - switch to use fwnode_property_count_uXX() - leds-lm3532: - fix brightness control for i2c mode - change the define for the fs current register - fixes for the driver for stability - add full scale current configuration - dt: Add property for full scale current. - avoid potentially unpaired regulator calls - move static keyword to the front of declarations - fix optional led-max-microamp prop error handling - leds-max77650: - add of_node_put() before return - add MODULE_ALIAS() - Switch to fwnode property API - leds-as3645a: - fix misuse of strlcpy - leds-netxbig: - add of_node_put() in netxbig_leds_get_of_pdata() - remove legacy board-file support - leds-is31fl319x: - simplify getting the adapter of a client - leds-ti-lmu-common: - fix coccinelle issue - move static keyword to the front of declaration - leds-syscon: - use resource managed variant of device register - leds-ktd2692: - fix a typo in the name of a constant - leds-lp5562: - allow firmware files up to the maximum length - leds-an30259a: - fix typo - leds-pca953x: - include the right header" * tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: (72 commits) leds: lm3532: Fix optional led-max-microamp prop error handling led: triggers: Fix dereferencing of null pointer leds: ti-lmu-common: Move static keyword to the front of declaration leds: lm3532: Move static keyword to the front of declarations leds: trigger: gpio: GPIO 0 is valid leds: pwm: Use struct_size() helper leds: is31fl32xx: Use struct_size() helper leds: ti-lmu-common: Fix coccinelle issue in TI LMU leds: lm3532: Avoid potentially unpaired regulator calls leds: syscon: Use resource managed variant of device register leds: Replace {devm_}led_classdev_register() macros with inlines leds: Allow to call led_classdev_unregister() unconditionally leds: lm3532: Add full scale current configuration dt: lm3532: Add property for full scale current. leds: lm3532: Fixes for the driver for stability leds: lm3532: Change the define for the fs current register leds: lm3532: Fix brightness control for i2c mode leds: Switch to use fwnode instead of be stuck with OF one leds: max77650: Switch to fwnode property API led: triggers: Fix a memory leak bug ...
| * | drivers: Introduce device lookup variants by fwnodeSuzuki K Poulose2019-07-301-7/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper to match the firmware node handle of a device and provide wrappers for {bus/class/driver}_find_device() APIs to avoid proliferation of duplicate custom match functions. Cc: "David S. Miller" <davem@davemloft.net> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: linux-usb@vger.kernel.org Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Joe Perches <joe@perches.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Joerg Roedel <joro@8bytes.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20190723221838.12024-4-suzuki.poulose@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge branches 'for-joerg/arm-smmu/smmu-v2' and 'for-joerg/arm-smmu/smmu-v3' ↵Will Deacon2019-08-231-24/+70
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into for-joerg/arm-smmu/updates * for-joerg/arm-smmu/smmu-v2: Refactoring to allow for implementation-specific hooks in 'arm-smmu-impl.c' * for-joerg/arm-smmu/smmu-v3: Support for deferred TLB invalidation and batching of commands Rework ATC invalidation for ATS-enabled PCIe masters
| * | iommu/io-pgtable: Pass struct iommu_iotlb_gather to ->tlb_add_page()Will Deacon2019-07-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | With all the pieces in place, we can finally propagate the iommu_iotlb_gather structure from the call to unmap() down to the IOMMU drivers' implementation of ->tlb_add_page(). Currently everybody ignores it, but the machinery is now there to defer invalidation. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu/io-pgtable: Pass struct iommu_iotlb_gather to ->unmap()Will Deacon2019-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | Update the io-pgtable ->unmap() function to take an iommu_iotlb_gather pointer as an argument, and update the callers as appropriate. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu/io-pgtable: Remove unused ->tlb_sync() callbackWill Deacon2019-07-291-8/+9
| | | | | | | | | | | | | | | | | | The ->tlb_sync() callback is no longer used, so it can be removed. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu/io-pgtable: Replace ->tlb_add_flush() with ->tlb_add_page()Will Deacon2019-07-291-31/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ->tlb_add_flush() callback in the io-pgtable API now looks a bit silly: - It takes a size and a granule, which are always the same - It takes a 'bool leaf', which is always true - It only ever flushes a single page With that in mind, replace it with an optional ->tlb_add_page() callback that drops the useless parameters. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu/io-pgtable: Hook up ->tlb_flush_walk() and ->tlb_flush_leaf() in driversWill Deacon2019-07-291-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Hook up ->tlb_flush_walk() and ->tlb_flush_leaf() in drivers using the io-pgtable API so that we can start making use of them in the page-table code. For now, they can just wrap the implementations of ->tlb_add_flush and ->tlb_sync pending future optimisation in each driver. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu: Pass struct iommu_iotlb_gather to ->unmap() and ->iotlb_sync()Will Deacon2019-07-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To allow IOMMU drivers to batch up TLB flushing operations and postpone them until ->iotlb_sync() is called, extend the prototypes for the ->unmap() and ->iotlb_sync() IOMMU ops callbacks to take a pointer to the current iommu_iotlb_gather structure. All affected IOMMU drivers are updated, but there should be no functional change since the extra parameter is ignored for now. Signed-off-by: Will Deacon <will@kernel.org>
| * | iommu/io-pgtable: Rename iommu_gather_ops to iommu_flush_opsWill Deacon2019-07-241-4/+4
| |/ | | | | | | | | | | | | | | | | | | | | In preparation for TLB flush gathering in the IOMMU API, rename the iommu_gather_ops structure in io-pgtable to iommu_flush_ops, which better describes its purpose and avoids the potential for confusion between different levels of the API. $ find linux/ -type f -name '*.[ch]' | xargs sed -i 's/gather_ops/flush_ops/g' Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Ensure 64-bit I/O accessors are available on 32-bit CPURobin Murphy2019-08-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | As part of the grand SMMU driver refactoring effort, the I/O register accessors were moved into 'arm-smmu.h' in commit 6d7dff62afb0 ("iommu/arm-smmu: Move Secure access quirk to implementation"). On 32-bit architectures (such as ARM), the 64-bit accessors are defined in 'linux/io-64-nonatomic-hi-lo.h', so include this header to fix the build. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Add context init implementation hookRobin Murphy2019-08-191-42/+9
| | | | | | | | | | | | | | | | | | | | Allocating and initialising a context for a domain is another point where certain implementations are known to want special behaviour. Currently the other half of the Cavium workaround comes into play here, so let's finish the job to get the whole thing right out of the way. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Add reset implementation hookRobin Murphy2019-08-191-35/+4
| | | | | | | | | | | | | | | | | | Reset is an activity rife with implementation-defined poking. Add a corresponding hook, and use it to encapsulate the existing MMU-500 details. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Add configuration implementation hookRobin Murphy2019-08-191-14/+3
| | | | | | | | | | | | | | | | | | | | Probing the ID registers and setting up the SMMU configuration is an area where overrides and workarounds may well be needed. Indeed, the Cavium workaround detection lives there at the moment, so let's break that out. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Move Secure access quirk to implementationRobin Murphy2019-08-191-97/+0
| | | | | | | | | | | | | | | | | | | | | | Move detection of the Secure access quirk to its new home, trimming it down in the process - time has proven that boolean DT flags are neither ideal nor necessarily sufficient, so it's highly unlikely we'll ever add more, let alone enough to justify the frankly overengineered parsing machinery. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Add implementation infrastructureRobin Murphy2019-08-191-78/+4
| | | | | | | | | | | | | | | | | | | | | | | | Add some nascent infrastructure for handling implementation-specific details outside the flow of the architectural code. This will allow us to keep mutually-incompatible vendor-specific hooks in their own files where the respective interested parties can maintain them with minimal chance of conflicts. As somewhat of a template, we'll start with a general place to collect the relatively trivial existing quirks. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
* | iommu/arm-smmu: Rename arm-smmu-regs.hRobin Murphy2019-08-191-1/+1
| | | | | | | | | | | | | | | | We're about to start using it for more than just register definitions, so generalise the name. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>