Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
5930df68 |
| 21-Mar-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
iommu/omap: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error ha
iommu/omap: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230321084125.337021-10-u.kleine-koenig@pengutronix.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17 |
|
#
0c043164 |
| 10-Mar-2023 |
Rob Herring <robh@kernel.org> |
iommu/omap: Use of_property_read_bool() for boolean properties
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/o
iommu/omap: Use of_property_read_bool() for boolean properties
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to of_property_read_bool().
Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20230310144709.1542980-1-robh@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
c1fe9119 |
| 09-Jan-2023 |
Lu Baolu <baolu.lu@linux.intel.com> |
iommu: Add set_platform_dma_ops callbacks
For those IOMMU drivers that don't provide default domain support, add an implementation of set_platform_dma_ops callback so that the IOMMU core could retur
iommu: Add set_platform_dma_ops callbacks
For those IOMMU drivers that don't provide default domain support, add an implementation of set_platform_dma_ops callback so that the IOMMU core could return the DMA control to platform DMA ops. At the same time, with the set_platform_dma_ops implemented, there is no need for detach_dev. Remove it to avoid dead code.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20230110025408.667767-4-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3 |
|
#
f4a14773 |
| 17-Oct-2022 |
Nicolin Chen <nicolinc@nvidia.com> |
iommu: Use EINVAL for incompatible device/domain in ->attach_dev
Following the new rules in include/linux/iommu.h kdocs, update all drivers ->attach_dev callback functions to return EINVAL in the fa
iommu: Use EINVAL for incompatible device/domain in ->attach_dev
Following the new rules in include/linux/iommu.h kdocs, update all drivers ->attach_dev callback functions to return EINVAL in the failure paths that are related to domain incompatibility.
Also, drop adjacent error prints to prevent a kernel log spam.
Link: https://lore.kernel.org/r/f52a07f7320da94afe575c9631340d0019a203a7.1666042873.git.nicolinc@nvidia.com Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
show more ...
|
#
bd7ebb77 |
| 17-Oct-2022 |
Nicolin Chen <nicolinc@nvidia.com> |
iommu: Regulate EINVAL in ->attach_dev callback functions
Following the new rules in include/linux/iommu.h kdocs, EINVAL now can be used to indicate that domain and device are incompatible by a call
iommu: Regulate EINVAL in ->attach_dev callback functions
Following the new rules in include/linux/iommu.h kdocs, EINVAL now can be used to indicate that domain and device are incompatible by a caller that treats it as a soft failure and tries attaching to another domain.
On the other hand, there are ->attach_dev callback functions returning it for obvious device-specific errors. They will result in some inefficiency in the caller handling routine.
Update these places to corresponding errnos following the new rules.
Link: https://lore.kernel.org/r/5924c03bea637f05feb2a20d624bae086b555ec5.1666042872.git.nicolinc@nvidia.com Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
show more ...
|
Revision tags: v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61 |
|
#
a2409086 |
| 15-Aug-2022 |
Robin Murphy <robin.murphy@arm.com> |
iommu/omap: Clean up bus_set_iommu()
Stop calling bus_set_iommu() since it's now unnecessary, and simplify the init failure path accordingly.
Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link
iommu/omap: Clean up bus_set_iommu()
Stop calling bus_set_iommu() since it's now unnecessary, and simplify the init failure path accordingly.
Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/b578af8e2bf8afeccb2c2ce87c1aa38b36f01331.1660572783.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
71ff461c |
| 31-Mar-2022 |
Tony Lindgren <tony@atomide.com> |
iommu/omap: Fix regression in probe for NULL pointer dereference
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started triggering a NULL pointer dereference for some omap varian
iommu/omap: Fix regression in probe for NULL pointer dereference
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started triggering a NULL pointer dereference for some omap variants:
__iommu_probe_device from probe_iommu_group+0x2c/0x38 probe_iommu_group from bus_for_each_dev+0x74/0xbc bus_for_each_dev from bus_iommu_probe+0x34/0x2e8 bus_iommu_probe from bus_set_iommu+0x80/0xc8 bus_set_iommu from omap_iommu_init+0x88/0xcc omap_iommu_init from do_one_initcall+0x44/0x24
This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV) as noted by Jason Gunthorpe <jgg@ziepe.ca>.
Looks like the regression already happened with an earlier commit 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") that changed the function return type and missed converting one place.
Cc: Drew Fustini <dfustini@baylibre.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Suman Anna <s-anna@ti.com> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Fixes: 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Drew Fustini <dfustini@baylibre.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20220331062301.24269-1-tony@atomide.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24 |
|
#
9a630a4b |
| 15-Feb-2022 |
Lu Baolu <baolu.lu@linux.intel.com> |
iommu: Split struct iommu_ops
Move the domain specific operations out of struct iommu_ops into a new structure that only has domain specific operations. This solves the problem of needing to know if
iommu: Split struct iommu_ops
Move the domain specific operations out of struct iommu_ops into a new structure that only has domain specific operations. This solves the problem of needing to know if the method vector for a given operation needs to be retrieved from the device or the domain. Logically the domain ops are the ones that make sense for external subsystems and endpoint drivers to use, while device ops, with the sole exception of domain_alloc, are IOMMU API internals.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20220216025249.3459465-10-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18 |
|
#
30209b93 |
| 28-Jan-2022 |
John Garry <john.garry@huawei.com> |
iommu: Fix some W=1 warnings
The code is mostly free of W=1 warning, so fix the following:
drivers/iommu/iommu.c:996: warning: expecting prototype for iommu_group_for_each_dev(). Prototype was for
iommu: Fix some W=1 warnings
The code is mostly free of W=1 warning, so fix the following:
drivers/iommu/iommu.c:996: warning: expecting prototype for iommu_group_for_each_dev(). Prototype was for __iommu_group_for_each_dev() instead drivers/iommu/iommu.c:3048: warning: Function parameter or member 'drvdata' not described in 'iommu_sva_bind_device' drivers/iommu/ioasid.c:354: warning: Function parameter or member 'ioasid' not described in 'ioasid_get' drivers/iommu/omap-iommu.c:1098: warning: expecting prototype for omap_iommu_suspend_prepare(). Prototype was for omap_iommu_prepare() instead
Signed-off-by: John Garry <john.garry@huawei.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/1643366673-26803-1-git-send-email-john.garry@huawei.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
47e23911 |
| 31-Mar-2022 |
Tony Lindgren <tony@atomide.com> |
iommu/omap: Fix regression in probe for NULL pointer dereference
[ Upstream commit 71ff461c3f41f6465434b9e980c01782763e7ad8 ]
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") star
iommu/omap: Fix regression in probe for NULL pointer dereference
[ Upstream commit 71ff461c3f41f6465434b9e980c01782763e7ad8 ]
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started triggering a NULL pointer dereference for some omap variants:
__iommu_probe_device from probe_iommu_group+0x2c/0x38 probe_iommu_group from bus_for_each_dev+0x74/0xbc bus_for_each_dev from bus_iommu_probe+0x34/0x2e8 bus_iommu_probe from bus_set_iommu+0x80/0xc8 bus_set_iommu from omap_iommu_init+0x88/0xcc omap_iommu_init from do_one_initcall+0x44/0x24
This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV) as noted by Jason Gunthorpe <jgg@ziepe.ca>.
Looks like the regression already happened with an earlier commit 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") that changed the function return type and missed converting one place.
Cc: Drew Fustini <dfustini@baylibre.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: Suman Anna <s-anna@ti.com> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca> Fixes: 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Drew Fustini <dfustini@baylibre.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20220331062301.24269-1-tony@atomide.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41 |
|
#
a4099d47 |
| 27-May-2021 |
Rob Herring <robh@kernel.org> |
iommu: Drop unnecessary of_iommu.h includes
The only place of_iommu.h is needed is in drivers/of/device.c. Remove it from everywhere else.
Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <robin.
iommu: Drop unnecessary of_iommu.h includes
The only place of_iommu.h is needed is in drivers/of/device.c. Remove it from everywhere else.
Cc: Will Deacon <will@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Yong Wu <yong.wu@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jean-Philippe Brucker <jean-philippe@linaro.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: iommu@lists.linux-foundation.org Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20210527193710.1281746-2-robh@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
2d471b20 |
| 01-Apr-2021 |
Robin Murphy <robin.murphy@arm.com> |
iommu: Streamline registration interface
Rather than have separate opaque setter functions that are easy to overlook and lead to repetitive boilerplate in drivers, let's pass the relevant initialisa
iommu: Streamline registration interface
Rather than have separate opaque setter functions that are easy to overlook and lead to repetitive boilerplate in drivers, let's pass the relevant initialisation parameters directly to iommu_device_register().
Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/ab001b87c533b6f4db71eb90db6f888953986c36.1617285386.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51 |
|
#
f512eefc |
| 08-Jul-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
iommu/omap: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: Fo
iommu/omap: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Link: https://lore.kernel.org/r/20200708210434.22518-1-grandmaster@al2klimov.de Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.4.50, v5.7.7 |
|
#
97ea1202 |
| 25-Jun-2020 |
Joerg Roedel <jroedel@suse.de> |
iommu/omap: Use dev_iommu_priv_get/set()
Remove the use of dev->archdata.iommu and use the private per-device pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel <jroedel@suse.
iommu/omap: Use dev_iommu_priv_get/set()
Remove the use of dev->archdata.iommu and use the private per-device pointer provided by IOMMU core code instead.
Signed-off-by: Joerg Roedel <jroedel@suse.de> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Link: https://lore.kernel.org/r/20200625130836.1916-5-joro@8bytes.org
show more ...
|
Revision tags: v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36 |
|
#
5df362a5 |
| 24-Apr-2020 |
Tero Kristo via iommu <iommu@lists.linux-foundation.org> |
iommu/omap: Add registration for DT fwnode pointer
The fwnode pointer must be passed to the iommu core, so that the core can map the IOMMU towards device requests properly. Without this, some IOMMU
iommu/omap: Add registration for DT fwnode pointer
The fwnode pointer must be passed to the iommu core, so that the core can map the IOMMU towards device requests properly. Without this, some IOMMU clients like OMAP remoteproc will fail the iommu configuration multiple times with -EPROBE_DEFER, which will eventually be ignored with a kernel warning banner.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Link: https://lore.kernel.org/r/20200424145828.3159-1-t-kristo@ti.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
46b14fc6 |
| 18-May-2020 |
Tero Kristo via iommu <iommu@lists.linux-foundation.org> |
iommu/omap: Add check for iommu group when no IOMMU in use
Most of the devices in OMAP family of SoCs are not using IOMMU. The patch for converting the OMAP IOMMU to use generic IOMMU bus probe func
iommu/omap: Add check for iommu group when no IOMMU in use
Most of the devices in OMAP family of SoCs are not using IOMMU. The patch for converting the OMAP IOMMU to use generic IOMMU bus probe functionality failed to add a check for this, so add it here.
Fixes: c822b37cac48 ("iommu/omap: Remove orphan_dev tracking") Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Link: https://lore.kernel.org/r/20200518111057.23140-1-t-kristo@ti.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
6785eb91 |
| 29-Apr-2020 |
Joerg Roedel <jroedel@suse.de> |
iommu/omap: Convert to probe/release_device() call-backs
Convert the OMAP IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the gr
iommu/omap: Convert to probe/release_device() call-backs
Convert the OMAP IOMMU driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup.
Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200429133712.31431-30-joro@8bytes.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
c822b37c |
| 29-Apr-2020 |
Joerg Roedel <jroedel@suse.de> |
iommu/omap: Remove orphan_dev tracking
Remove the tracking of device which could not be probed because their IOMMU is not probed yet. Replace it with a call to bus_iommu_probe() when a new IOMMU is
iommu/omap: Remove orphan_dev tracking
Remove the tracking of device which could not be probed because their IOMMU is not probed yet. Replace it with a call to bus_iommu_probe() when a new IOMMU is probed.
Signed-off-by: Joerg Roedel <jroedel@suse.de> Link: https://lore.kernel.org/r/20200429133712.31431-29-joro@8bytes.org Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24 |
|
#
6135a891 |
| 03-Mar-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
iommu/omap: Fix printing format for size_t on 64-bit
Print size_t as %zu or %zx to fix -Wformat warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST):
drivers/iommu/omap-iommu.c:
iommu/omap: Fix printing format for size_t on 64-bit
Print size_t as %zu or %zx to fix -Wformat warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST):
drivers/iommu/omap-iommu.c: In function ‘flush_iotlb_page’: drivers/iommu/omap-iommu.c:437:47: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
f2ce16c3 |
| 03-Mar-2020 |
Krzysztof Kozlowski <krzk@kernel.org> |
iommu/omap: Fix pointer cast -Wpointer-to-int-cast warnings on 64 bit
pointers should be casted to unsigned long to avoid -Wpointer-to-int-cast warnings when compiling on 64-bit platform (e.g. with
iommu/omap: Fix pointer cast -Wpointer-to-int-cast warnings on 64 bit
pointers should be casted to unsigned long to avoid -Wpointer-to-int-cast warnings when compiling on 64-bit platform (e.g. with COMPILE_TEST):
drivers/iommu/omap-iommu.c: In function ‘omap2_iommu_enable’: drivers/iommu/omap-iommu.c:170:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] if (!obj->iopgd || !IS_ALIGNED((u32)obj->iopgd, SZ_16K)) ^
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8 |
|
#
781ca2de |
| 08-Sep-2019 |
Tom Murphy <murphyt7@tcd.ie> |
iommu: Add gfp parameter to iommu_ops::map
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 f
iommu: Add gfp parameter to iommu_ops::map
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>
show more ...
|
#
96088a20 |
| 06-Sep-2019 |
Arnd Bergmann <arnd@arndb.de> |
iommu/omap: Mark pm functions __maybe_unused
The runtime_pm functions are unused when CONFIG_PM is disabled:
drivers/iommu/omap-iommu.c:1022:12: error: unused function 'omap_iommu_runtime_suspend'
iommu/omap: Mark pm functions __maybe_unused
The runtime_pm functions are unused when CONFIG_PM is disabled:
drivers/iommu/omap-iommu.c:1022:12: error: unused function 'omap_iommu_runtime_suspend' [-Werror,-Wunused-function] static int omap_iommu_runtime_suspend(struct device *dev) drivers/iommu/omap-iommu.c:1064:12: error: unused function 'omap_iommu_runtime_resume' [-Werror,-Wunused-function] static int omap_iommu_runtime_resume(struct device *dev)
Mark them as __maybe_unused to let gcc silently drop them instead of warning.
Fixes: db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm callbacks") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Suman Anna <s-anna@ti.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
24ce0bab |
| 16-Aug-2019 |
Suman Anna <s-anna@ti.com> |
iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN
The macro SLAB_HWCACHE_ALIGN is of type slab_flags_t, but is currently assigned in the OMAP IOMMU driver using a unsigned long variable. This
iommu/omap: Use the correct type for SLAB_HWCACHE_ALIGN
The macro SLAB_HWCACHE_ALIGN is of type slab_flags_t, but is currently assigned in the OMAP IOMMU driver using a unsigned long variable. This generates a sparse warning around the type check. Fix this by defining the variable flags using the correct type.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.2.9, v5.2.8 |
|
#
1432ebbd |
| 07-Aug-2019 |
Tero Kristo <t-kristo@ti.com> |
iommu/omap: remove pm_runtime_irq_safe flag for OMAP IOMMUs
This is not needed for anything, and prevents proper PM transitions for parent devices which is bad in case of ti-sysc; this effectively k
iommu/omap: remove pm_runtime_irq_safe flag for OMAP IOMMUs
This is not needed for anything, and prevents proper PM transitions for parent devices which is bad in case of ti-sysc; this effectively kills PM completely. Thus, remove the flag.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
#
604629bc |
| 07-Aug-2019 |
Tero Kristo <t-kristo@ti.com> |
iommu/omap: add support for late attachment of iommu devices
Current implementation of OMAP IOMMU enforces strict ordering of device probe, initiated by iommu and followed by remoteproc later. This
iommu/omap: add support for late attachment of iommu devices
Current implementation of OMAP IOMMU enforces strict ordering of device probe, initiated by iommu and followed by remoteproc later. This doesn't work too well with the new setup done with ti-sysc changes which may have the devices probed at pretty much any order. To overcome this limitation, if iommu has not been probed yet when a consumer tries to attach to it, add the device to orphan device list which will be parsed during iommu probe to see if any orphan devices should be attached.
Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|