Centos-kernel-stream-9/drivers/of/device.c

276 lines
7.4 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
#include <linux/kernel.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_address.h>
#include <linux/of_iommu.h>
#include <linux/of_reserved_mem.h>
#include <linux/dma-direct.h> /* for bus_dma_region */
#include <linux/dma-map-ops.h>
#include <linux/init.h>
#include <linux/mod_devicetable.h>
#include <linux/slab.h>
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
#include <linux/platform_device.h>
#include <asm/errno.h>
#include "of_private.h"
/**
* of_match_device - Tell if a struct device matches an of_device_id list
* @matches: array of of device match structures to search in
* @dev: the of device structure to match against
*
* Used by a driver to check whether an platform_device present in the
* system is in its list of supported devices.
*/
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
of: Check 'of_node_reused' flag on of_match_device() Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit 9b22c17a3cc5f61b195da624cbb48634b4e42055 Author: Rob Herring <robh@kernel.org> Date: Tue Jan 18 11:34:04 2022 -0600 of: Check 'of_node_reused' flag on of_match_device() Commit 0f153a1b8193 ("usb: chipidea: Set the DT node on the child device") caused the child device to match on the parent driver instead of the child's driver since the child's DT node pointer matched. The worst case result is a loop of the parent driver probing another instance and creating yet another child device eventually exhausting the stack. If the child driver happens to match first, then everything works fine. A device sharing the DT node should never do DT based driver matching, so let's simply check of_node_reused in of_match_device() to prevent that. Fixes: 0f153a1b8193 ("usb: chipidea: Set the DT node on the child device") Link: https://lore.kernel.org/all/20220114105620.GK18506@ediswmail.ad.cirrus.com/ Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Tony Lindgren <tony@atomide.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Peter Chen <peter.chen@nxp.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220118173404.1891800-1-robh@kernel.org (cherry picked from commit 9b22c17a3cc5f61b195da624cbb48634b4e42055) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:55 +00:00
if (!matches || !dev->of_node || dev->of_node_reused)
return NULL;
return of_match_node(matches, dev->of_node);
}
EXPORT_SYMBOL(of_match_device);
of: restricted dma: Don't fail device probe on rmem init failure Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit f3cfd136aef0184919464b49d5b74d43605abcbc Author: Will Deacon <will@kernel.org> Date: Mon Aug 16 14:26:17 2021 +0100 of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit f3cfd136aef0184919464b49d5b74d43605abcbc) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:37 +00:00
static void
of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
{
struct device_node *node, *of_node = dev->of_node;
int count, i;
of: restricted dma: Don't fail device probe on rmem init failure Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit f3cfd136aef0184919464b49d5b74d43605abcbc Author: Will Deacon <will@kernel.org> Date: Mon Aug 16 14:26:17 2021 +0100 of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit f3cfd136aef0184919464b49d5b74d43605abcbc) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:37 +00:00
if (!IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL))
return;
count = of_property_count_elems_of_size(of_node, "memory-region",
sizeof(u32));
/*
* If dev->of_node doesn't exist or doesn't contain memory-region, try
* the OF node having DMA configuration.
*/
if (count <= 0) {
of_node = np;
count = of_property_count_elems_of_size(
of_node, "memory-region", sizeof(u32));
}
for (i = 0; i < count; i++) {
node = of_parse_phandle(of_node, "memory-region", i);
/*
* There might be multiple memory regions, but only one
* restricted-dma-pool region is allowed.
*/
if (of_device_is_compatible(node, "restricted-dma-pool") &&
of_device_is_available(node))
of: restricted dma: Don't fail device probe on rmem init failure Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit f3cfd136aef0184919464b49d5b74d43605abcbc Author: Will Deacon <will@kernel.org> Date: Mon Aug 16 14:26:17 2021 +0100 of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit f3cfd136aef0184919464b49d5b74d43605abcbc) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:37 +00:00
break;
}
/*
* Attempt to initialize a restricted-dma-pool region if one was found.
* Note that count can hold a negative error code.
*/
if (i < count && of_reserved_mem_device_init_by_idx(dev, of_node, i))
of: restricted dma: Don't fail device probe on rmem init failure Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit f3cfd136aef0184919464b49d5b74d43605abcbc Author: Will Deacon <will@kernel.org> Date: Mon Aug 16 14:26:17 2021 +0100 of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit f3cfd136aef0184919464b49d5b74d43605abcbc) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:37 +00:00
dev_warn(dev, "failed to initialise \"restricted-dma-pool\" memory node\n");
}
/**
* of_dma_configure_id - Setup DMA configuration
* @dev: Device to apply DMA configuration
* @np: Pointer to OF node having DMA configuration
* @force_dma: Whether device is to be set up by of_dma_configure() even if
* DMA capability is not explicitly described by firmware.
* @id: Optional const pointer value input id
*
* Try to get devices's DMA configuration from DT and update it
* accordingly.
*
* If platform code needs to use its own special DMA configuration, it
* can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
* to fix up DMA configuration.
*/
int of_dma_configure_id(struct device *dev, struct device_node *np,
bool force_dma, const u32 *id)
{
const struct bus_dma_region *map = NULL;
of: Fix "dma-ranges" handling for bus controllers JIRA: https://issues.redhat.com/browse/RHEL-28780 Upstream Status: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git commit f1ad5338a4d57fe1fe6475003acb8c70bf9d1bdf Author: Robin Murphy <robin.murphy@arm.com> Date: Thu Sep 29 13:48:38 2022 +0100 of: Fix "dma-ranges" handling for bus controllers Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes") relaxed the handling of "dma-ranges" for any leaf node on the assumption that it would still represent a usage error for the property to be present on a non-bus leaf node. However there turns out to be a fiddly case where a bus also represents a DMA-capable device in its own right, such as a PCIe root complex with an integrated DMA engine on its platform side. In such cases, "dma-ranges" translation is entirely valid for devices discovered behind the bus, but should not be erroneously applied to the bus controller device itself which operates in its parent's address space. Fix this by restoring the previous behaviour for the specific case where a device is configured via its own OF node, since it is logical to assume that a device should never represent its own parent bus. Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/112e8f3d3e7c054ecf5e12b5ac0aa5596ec00681.1664455433.git.robin.murphy@arm.com Signed-off-by: Rob Herring <robh@kernel.org> (cherry picked from commit f1ad5338a4d57fe1fe6475003acb8c70bf9d1bdf) Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
2022-09-29 12:48:38 +00:00
struct device_node *bus_np;
u64 mask, end = 0;
bool coherent, set_map = false;
int ret;
of: Fix "dma-ranges" handling for bus controllers JIRA: https://issues.redhat.com/browse/RHEL-28780 Upstream Status: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git commit f1ad5338a4d57fe1fe6475003acb8c70bf9d1bdf Author: Robin Murphy <robin.murphy@arm.com> Date: Thu Sep 29 13:48:38 2022 +0100 of: Fix "dma-ranges" handling for bus controllers Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes") relaxed the handling of "dma-ranges" for any leaf node on the assumption that it would still represent a usage error for the property to be present on a non-bus leaf node. However there turns out to be a fiddly case where a bus also represents a DMA-capable device in its own right, such as a PCIe root complex with an integrated DMA engine on its platform side. In such cases, "dma-ranges" translation is entirely valid for devices discovered behind the bus, but should not be erroneously applied to the bus controller device itself which operates in its parent's address space. Fix this by restoring the previous behaviour for the specific case where a device is configured via its own OF node, since it is logical to assume that a device should never represent its own parent bus. Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/112e8f3d3e7c054ecf5e12b5ac0aa5596ec00681.1664455433.git.robin.murphy@arm.com Signed-off-by: Rob Herring <robh@kernel.org> (cherry picked from commit f1ad5338a4d57fe1fe6475003acb8c70bf9d1bdf) Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
2022-09-29 12:48:38 +00:00
if (np == dev->of_node)
bus_np = __of_get_dma_parent(np);
else
bus_np = of_node_get(np);
ret = of_dma_get_range(bus_np, &map);
of_node_put(bus_np);
if (ret < 0) {
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
/*
* For legacy reasons, we have to assume some devices need
* DMA configuration regardless of whether "dma-ranges" is
* correctly specified or not.
*/
if (!force_dma)
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
return ret == -ENODEV ? 0 : ret;
} else {
/* Determine the overall bounds of all DMA regions */
end = dma_range_map_max(map);
set_map = true;
}
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
/*
* If @dev is expected to be DMA-capable then the bus code that created
* it should have initialised its dma_mask pointer by this point. For
* now, we'll continue the legacy behaviour of coercing it to the
* coherent mask if not, but we'll no longer do so quietly.
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
*/
if (!dev->dma_mask) {
dev_warn(dev, "DMA mask not set\n");
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
dev->dma_mask = &dev->coherent_dma_mask;
}
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
if (!end && dev->coherent_dma_mask)
end = dev->coherent_dma_mask;
else if (!end)
end = (1ULL << 32) - 1;
of: restrict DMA configuration Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-31 10:32:54 +00:00
/*
* Limit coherent and dma mask based on size and default mask
* set by the driver.
*/
mask = DMA_BIT_MASK(ilog2(end) + 1);
of: fix DMA mask generation Historically, DMA masks have suffered some ambiguity between whether they represent the range of physical memory a device can access, or the address bits a device is capable of driving, particularly since on many platforms the two are equivalent. Whilst there are some stragglers left (dma_max_pfn(), I'm looking at you...), the majority of DMA code has been cleaned up to follow the latter definition, not least since it is the only one which makes sense once IOMMUs are involved. In this respect, of_dma_configure() has always done the wrong thing in how it generates initial masks based on "dma-ranges". Although rounding down did not affect the TI Keystone platform where dma_addr + size is already a power of two, in any other case it results in a mask which is at best unnecessarily constrained and at worst unusable. BCM2837 illustrates the problem nicely, where we have a DMA base of 3GB and a size of 1GB - 16MB, giving dma_addr + size = 0xff000000 and a resultant mask of 0x7fffffff, which is then insufficient to even cover the necessary offset, effectively making all DMA addresses out-of-range. This has been hidden until now (mostly because we don't yet prevent drivers from simply overwriting this initial mask later upon probe), but due to recent changes elsewhere now shows up as USB being broken on Raspberry Pi 3. Make it right by rounding up instead of down, such that the mask correctly correctly describes all possisble bits the device needs to emit. Fixes: 9a6d7298b083 ("of: Calculate device DMA masks based on DT dma-range size") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Reported-by: Andreas Färber <afaerber@suse.de> Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2017-08-11 16:29:56 +00:00
dev->coherent_dma_mask &= mask;
*dev->dma_mask &= mask;
/* ...but only set bus limit and range map if we found valid dma-ranges earlier */
if (set_map) {
dev->bus_dma_limit = end;
dev->dma_range_map = map;
}
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
ret = of_iommu_configure(dev, np, id);
if (ret == -EPROBE_DEFER) {
/* Don't touch range map if it wasn't set from a valid dma-ranges */
if (set_map)
dev->dma_range_map = NULL;
kfree(map);
return -EPROBE_DEFER;
}
/* Take all other IOMMU errors to mean we'll just carry on without it */
dev_dbg(dev, "device is%sbehind an iommu\n",
!ret ? " " : " not ");
arch_setup_dma_ops(dev, coherent);
if (ret)
of: restricted dma: Don't fail device probe on rmem init failure Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071840 Tested: This is one of a series of patch sets to enable Arm SystemReady IR support in the kernel for NXP i.MX8 platforms. At this stage, this has been tested by ensuring we can survive the CI/CD loop -- i.e., that we have not broken anything else, and a simple boot test. When sufficient drivers have been brought in for i.MX8M, we will be able to run further tests. commit f3cfd136aef0184919464b49d5b74d43605abcbc Author: Will Deacon <will@kernel.org> Date: Mon Aug 16 14:26:17 2021 +0100 of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit f3cfd136aef0184919464b49d5b74d43605abcbc) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-06-30 22:34:37 +00:00
of_dma_set_restricted_buffer(dev, np);
return 0;
}
EXPORT_SYMBOL_GPL(of_dma_configure_id);
const void *of_device_get_match_data(const struct device *dev)
{
const struct of_device_id *match;
match = of_match_device(dev->driver->of_match_table, dev);
if (!match)
return NULL;
return match->data;
}
EXPORT_SYMBOL(of_device_get_match_data);
/**
* of_device_modalias - Fill buffer with newline terminated modalias string
* @dev: Calling device
* @str: Modalias string
* @len: Size of @str
*/
ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
{
ssize_t sl;
if (!dev || !dev->of_node || dev->of_node_reused)
return -ENODEV;
sl = of_modalias(dev->of_node, str, len - 2);
if (sl < 0)
return sl;
if (sl > len - 2)
return -ENOMEM;
str[sl++] = '\n';
str[sl] = 0;
return sl;
}
EXPORT_SYMBOL_GPL(of_device_modalias);
/**
* of_device_uevent - Display OF related uevent information
* @dev: Device to display the uevent information for
* @env: Kernel object's userspace event reference to fill up
*/
void of_device_uevent(const struct device *dev, struct kobj_uevent_env *env)
{
const char *compat, *type;
struct alias_prop *app;
struct property *p;
int seen = 0;
if ((!dev) || (!dev->of_node))
return;
add_uevent_var(env, "OF_NAME=%pOFn", dev->of_node);
add_uevent_var(env, "OF_FULLNAME=%pOF", dev->of_node);
type = of_node_get_device_type(dev->of_node);
if (type)
add_uevent_var(env, "OF_TYPE=%s", type);
/* Since the compatible field can contain pretty much anything
* it's not really legal to split it out with commas. We split it
* up using a number of environment variables instead. */
of_property_for_each_string(dev->of_node, "compatible", p, compat) {
add_uevent_var(env, "OF_COMPATIBLE_%d=%s", seen, compat);
seen++;
}
add_uevent_var(env, "OF_COMPATIBLE_N=%d", seen);
seen = 0;
mutex_lock(&of_mutex);
list_for_each_entry(app, &aliases_lookup, link) {
if (dev->of_node == app->np) {
add_uevent_var(env, "OF_ALIAS_%d=%s", seen,
app->alias);
seen++;
}
}
mutex_unlock(&of_mutex);
}
EXPORT_SYMBOL_GPL(of_device_uevent);
of: device: make of_device_uevent_modalias() take a const device * Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.3-rc1 commit a77ad4bf792652340ab334956e69b46ec2fdaefb Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> AuthorDate: Wed Jan 11 12:30:03 2023 +0100 Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CommitDate: Fri Jan 27 13:45:28 2023 +0100 of_device_uevent_modalias() does not modify the device pointer passed to it, so mark it constant. In order to properly do this, a number of busses need to have a modalias function added as they were attempting to just point to of_device_uevent_modalias instead of their bus-specific modalias function. This is fine except if the prototype for a bus and device type modalias function diverges and then problems could happen. To prevent all of that, just wrap the call to of_device_uevent_modalias() directly for each bus and device type individually. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Samuel Holland <samuel@sholland.org> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Liang He <windhl@126.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Lyude Paul <lyude@redhat.com> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: Zou Wei <zou_wei@huawei.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-sunxi@lists.linux.dev Cc: dri-devel@lists.freedesktop.org Cc: devicetree@vger.kernel.org Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 12:10:44 +00:00
int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *env)
{
int sl;
if ((!dev) || (!dev->of_node) || dev->of_node_reused)
return -ENODEV;
/* Devicetree modalias is tricky, we add it in 2 steps */
if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
sl = of_modalias(dev->of_node, &env->buf[env->buflen-1],
sizeof(env->buf) - env->buflen);
if (sl < 0)
return sl;
if (sl >= (sizeof(env->buf) - env->buflen))
return -ENOMEM;
env->buflen += sl;
return 0;
}
EXPORT_SYMBOL_GPL(of_device_uevent_modalias);