From: sricharan@codeaurora.org (Sricharan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V5 05/12] drivers: platform: Configure dma operations at probe time
Date: Fri, 20 Jan 2017 11:55:40 +0530 [thread overview]
Message-ID: <000f01d272e6$08eba070$1ac2e150$@codeaurora.org> (raw)
In-Reply-To: <20170119190250.GA11181@red-moon>
Hi,
>
>> > pci_bus_add_devices (platform/amba)(_device_create/driver_register)
>> > | |
>> > pci_bus_add_device (device_add/driver_register)
>> > | |
>> > device_attach device_initial_probe
>> > | |
>> > __device_attach_driver __device_attach_driver
>> > |
>> > driver_probe_device
>> > |
>> > really_probe
>> > |
>> > dma_configure
>> >
>> > Similarly on the device/driver_unregister path __device_release_driver is
>> > called which inturn calls dma_deconfigure.
>> >
>> > Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> > ---
>> > * Removed the dma configuration for the pci devices in case of DT
>> > from pci_dma_configure which was hanging outside separately and
>> > doing it in dma_configure function itself.
>> >
>> > drivers/base/dd.c | 9 +++++++++
>> > drivers/base/dma-mapping.c | 32 ++++++++++++++++++++++++++++++++
>> > drivers/of/platform.c | 5 +----
>> > drivers/pci/probe.c | 5 +----
>> > include/linux/dma-mapping.h | 3 +++
>> > 5 files changed, 46 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> > index a1fbf55..4882f06 100644
>> > --- a/drivers/base/dd.c
>> > +++ b/drivers/base/dd.c
>> > @@ -19,6 +19,7 @@
>> >
>> > #include <linux/device.h>
>> > #include <linux/delay.h>
>> > +#include <linux/dma-mapping.h>
>> > #include <linux/module.h>
>> > #include <linux/kthread.h>
>> > #include <linux/wait.h>
>> > @@ -356,6 +357,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>> > if (ret)
>> > goto pinctrl_bind_failed;
>> >
>> > + ret = dma_configure(dev);
>> > + if (ret)
>> > + goto dma_failed;
>> > +
>> > if (driver_sysfs_add(dev)) {
>> > printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
>> > __func__, dev_name(dev));
>> > @@ -417,6 +422,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>> > goto done;
>> >
>> > probe_failed:
>> > + dma_deconfigure(dev);
>> > +dma_failed:
>> > if (dev->bus)
>> > blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
>> > BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
>> > @@ -826,6 +833,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
>> > drv->remove(dev);
>> >
>> > device_links_driver_cleanup(dev);
>> > + dma_deconfigure(dev);
>> > +
>> > devres_release_all(dev);
>> > dev->driver = NULL;
>> > dev_set_drvdata(dev, NULL);
>> > diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> > index efd71cf..dfe6fd7 100644
>> > --- a/drivers/base/dma-mapping.c
>> > +++ b/drivers/base/dma-mapping.c
>> > @@ -10,6 +10,7 @@
>> > #include <linux/dma-mapping.h>
>> > #include <linux/export.h>
>> > #include <linux/gfp.h>
>> > +#include <linux/of_device.h>
>> > #include <linux/slab.h>
>> > #include <linux/vmalloc.h>
>> >
>> > @@ -341,3 +342,34 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
>> > vunmap(cpu_addr);
>> > }
>> > #endif
>> > +
>> > +/*
>> > + * Common configuration to enable DMA API use for a device
>> > + */
>> > +#include <linux/pci.h>
>> > +
>> > +int dma_configure(struct device *dev)
>> > +{
>> > + struct device *_dev = dev;
>> > + int is_pci = dev_is_pci(dev);
>> > +
>> > + if (is_pci) {
>> > + _dev = pci_get_host_bridge_device(to_pci_dev(dev));
>> > + if (IS_ENABLED(CONFIG_OF) && _dev->parent &&
>> > + _dev->parent->of_node)
>> > + _dev = _dev->parent;
>> > + }
>> > +
>> > + if (_dev->of_node)
>> > + of_dma_configure(dev, _dev->of_node);
>> > +
>> > + if (is_pci)
>> > + pci_put_host_bridge_device(_dev);
>>
>> There's a fun bug here - at this point _dev is the *parent* of the
>> bridge device, so we put the refcount on the wrong device (the platform
>> device representing the host controller, rather than the PCI device
>> representing its insides), which frees the guy we're in the middle of
>> probing, and things rapidly go wrong afterwards:
>>
>> [ 1.461026] bus: 'platform': driver_probe_device: matched device
>> 40000000.pcie-controller with driver pci-host-generic
>> [ 1.471640] bus: 'platform': really_probe: probing driver
>> pci-host-generic with device 40000000.pcie-controller
>> [ 1.481678] OF: PCI: host bridge /pcie-controller at 40000000 ranges:
>>
>> ...
>>
>> [ 2.158259] bus: 'pci': driver_probe_device: matched device
>> 0000:02:10.0 with driver pcieport
>> [ 2.166716] bus: 'pci': really_probe: probing driver pcieport with
>> device 0000:02:10.0
>> [ 2.174590] pci 0000:02:10.0: Driver pcieport requests probe deferral
>> [ 2.180978] pci 0000:02:10.0: Added to deferred list
>> [ 2.185915] bus: 'pci': driver_probe_device: matched device
>> 0000:02:1f.0 with driver pcieport
>> [ 2.194366] bus: 'pci': really_probe: probing driver pcieport with
>> device 0000:02:1f.0
>> [ 2.202237] pci 0000:02:1f.0: Driver pcieport requests probe deferral
>> [ 2.208625] pci 0000:02:1f.0: Added to deferred list
>> [ 2.213582] driver: 'pci-host-generic': driver_bound: bound to device
>> '???v????.pcie-controller'
>> [ 2.222293] bus: 'platform': really_probe: bound device
>> ???v????.pcie-controller to driver pci-host-generic
>> [ 2.232041] Unable to handle kernel NULL pointer dereference at
>> virtual address 00000000
>>
>> I recall debugging this same issue before, and I seem to have a local
>> version of this commit dated about 6 weeks ago where dma_configure()
>> looks like this:
>>
>> --->8---
>> int dma_configure(struct device *dev)
>> {
>> struct device *bridge = NULL, *dma_dev = dev;
>>
>> if (dev_is_pci(dev)) {
>> bridge = pci_get_host_bridge_device(to_pci_dev(dev));
>> dma_dev = bridge->parent;
>
>This would break ACPI, dma_dev would be NULL here, so from
>this standpoint (ACPI) the current patch is correct (but those [dev,_dev]
>should be renamed, they are extremely misleading so naming as
>in this hunk, which fixes DT too, is very welcome).
>
Ya, I was also thinking about the _ variable names in first place.
So i will use the names that Robin showed in his hunk and fix the
DT case that he pointed out.
Regards,
Sricharan
>On ACPI the DMA attributes are checked on the bridge's companion
>(ie its associated acpi_device).
next prev parent reply other threads:[~2017-01-20 6:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-19 15:05 [PATCH V5 00/12] IOMMU probe deferral support Sricharan R
2017-01-19 15:05 ` [PATCH V5 01/12] iommu/of: Refactor of_iommu_configure() for error handling Sricharan R
2017-01-19 15:05 ` [PATCH V5 02/12] iommu/of: Prepare for deferred IOMMU configuration Sricharan R
2017-01-19 15:05 ` [PATCH V5 03/12] of: dma: Move range size workaround to of_dma_get_range() Sricharan R
2017-01-19 15:05 ` [PATCH V5 04/12] of: dma: Make of_dma_deconfigure() public Sricharan R
2017-01-19 15:05 ` [PATCH V5 05/12] drivers: platform: Configure dma operations at probe time Sricharan R
2017-01-19 16:48 ` Lorenzo Pieralisi
2017-01-20 5:34 ` Sricharan
2017-01-19 17:49 ` Robin Murphy
2017-01-19 19:02 ` Lorenzo Pieralisi
2017-01-20 6:25 ` Sricharan [this message]
2017-01-20 6:18 ` Sricharan
2017-01-19 15:05 ` [PATCH V5 06/12] iommu: of: Handle IOMMU lookup failure with deferred probing or error Sricharan R
2017-01-19 15:05 ` [PATCH V5 07/12] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops Sricharan R
2017-01-19 16:20 ` Will Deacon
2017-01-19 15:05 ` [PATCH V5 08/12] iommu/arm-smmu: Clean up early-probing workarounds Sricharan R
2017-01-19 16:18 ` Will Deacon
2017-01-20 19:20 ` Sricharan
2017-01-19 16:50 ` Lorenzo Pieralisi
2017-01-19 17:58 ` Robin Murphy
2017-01-20 6:32 ` Sricharan
2017-01-19 15:05 ` [PATCH V5 09/12] ACPI/IORT: Add function to check SMMUs drivers presence Sricharan R
2017-01-19 15:05 ` [PATCH V5 10/12] drivers: acpi: Configure acpi devices dma operation at probe time Sricharan R
2017-01-19 16:42 ` Lorenzo Pieralisi
2017-01-20 5:31 ` Sricharan
2017-01-19 15:05 ` [PATCH V5 11/12] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error Sricharan R
2017-01-19 15:05 ` [PATCH V5 12/12] ACPI/IORT: Remove linker section for IORT entries probing Sricharan R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000f01d272e6$08eba070$1ac2e150$@codeaurora.org' \
--to=sricharan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).