The dmaengine core assumes that async DMA devices will only be removed
when they not used anymore, or it assumes dma_async_device_unregister()
will only be called by dma driver exit routines. But this assumption is
not true for the IOAT driver, which calls dma_async_device_unregister()
from ioat_remove(). So current IOAT driver doesn't support device
hot-removal because it may cause system crash to hot-remove an inuse
IOAT device.
To support CPU socket hot-removal, all PCI devices, including IOAT
devices embedded in the socket, will be hot-removed. The idea solution
is to enhance the dmaengine core and IOAT driver to support hot-removal,
but that's too hard.
This patch implements a hack to disable IOAT devices under hotplug-capable
CPU socket so it won't break socket hot-removal.
Signed-off-by: Jiang Liu <[email protected]>
---
drivers/dma/ioat/pci.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
index 76f0dc688a19..3b8c9b03f4b3 100644
--- a/drivers/dma/ioat/pci.c
+++ b/drivers/dma/ioat/pci.c
@@ -27,6 +27,7 @@
#include <linux/interrupt.h>
#include <linux/dca.h>
#include <linux/slab.h>
+#include <linux/acpi.h>
#include "dma.h"
#include "dma_v2.h"
#include "registers.h"
@@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
return d;
}
+/*
+ * The dmaengine core assumes that async DMA devices will only be removed
+ * when they not used anymore, or it assumes dma_async_device_unregister()
+ * will only be called by dma driver exit routines. But this assumption is
+ * not true for the IOAT driver, which calls dma_async_device_unregister()
+ * from ioat_remove(). So current IOAT driver doesn't support device
+ * hot-removal because it may cause system crash to hot-remove inuse IOAT
+ * devices.
+ *
+ * This is a hack to disable IOAT devices under ejectable PCI host bridge
+ * so it won't break PCI host bridge hot-removal.
+ */
+static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
+{
+#ifdef CONFIG_ACPI
+ struct pci_bus *bus = pdev->bus;
+ struct acpi_device *adev;
+
+ while (bus->parent)
+ bus = bus->parent;
+ for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
+ if (adev->flags.ejectable)
+ return true;
+#endif
+
+ return false;
+}
+
static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
void __iomem * const *iomap;
@@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
struct ioatdma_device *device;
int err;
+ if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
+ dev_dbg(&pdev->dev, "ignore ejectable IOAT device.\n");
+ return -ENODEV;
+ }
+
err = pcim_enable_device(pdev);
if (err)
return err;
--
1.7.10.4
Ccing Rafael, it's ACPI hotplug related.
On 2015/6/2 14:36, Jiang Liu wrote:
> The dmaengine core assumes that async DMA devices will only be removed
> when they not used anymore, or it assumes dma_async_device_unregister()
> will only be called by dma driver exit routines. But this assumption is
> not true for the IOAT driver, which calls dma_async_device_unregister()
> from ioat_remove(). So current IOAT driver doesn't support device
> hot-removal because it may cause system crash to hot-remove an inuse
> IOAT device.
>
> To support CPU socket hot-removal, all PCI devices, including IOAT
> devices embedded in the socket, will be hot-removed. The idea solution
> is to enhance the dmaengine core and IOAT driver to support hot-removal,
> but that's too hard.
>
> This patch implements a hack to disable IOAT devices under hotplug-capable
> CPU socket so it won't break socket hot-removal.
>
> Signed-off-by: Jiang Liu <[email protected]>
> ---
> drivers/dma/ioat/pci.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
> index 76f0dc688a19..3b8c9b03f4b3 100644
> --- a/drivers/dma/ioat/pci.c
> +++ b/drivers/dma/ioat/pci.c
> @@ -27,6 +27,7 @@
> #include <linux/interrupt.h>
> #include <linux/dca.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
> #include "dma.h"
> #include "dma_v2.h"
> #include "registers.h"
> @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
> return d;
> }
>
> +/*
> + * The dmaengine core assumes that async DMA devices will only be removed
> + * when they not used anymore, or it assumes dma_async_device_unregister()
> + * will only be called by dma driver exit routines. But this assumption is
> + * not true for the IOAT driver, which calls dma_async_device_unregister()
> + * from ioat_remove(). So current IOAT driver doesn't support device
> + * hot-removal because it may cause system crash to hot-remove inuse IOAT
> + * devices.
> + *
> + * This is a hack to disable IOAT devices under ejectable PCI host bridge
> + * so it won't break PCI host bridge hot-removal.
> + */
> +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
> +{
> +#ifdef CONFIG_ACPI
> + struct pci_bus *bus = pdev->bus;
> + struct acpi_device *adev;
> +
> + while (bus->parent)
> + bus = bus->parent;
> + for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
> + if (adev->flags.ejectable)
> + return true;
> +#endif
> +
> + return false;
> +}
> +
> static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> {
> void __iomem * const *iomap;
> @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> struct ioatdma_device *device;
> int err;
>
> + if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
> + dev_dbg(&pdev->dev, "ignore ejectable IOAT device.\n");
> + return -ENODEV;
> + }
> +
> err = pcim_enable_device(pdev);
> if (err)
> return err;
>
On Tue, Jun 02, 2015 at 02:37:31PM +0800, Jiang Liu wrote:
> Ccing Rafael, it's ACPI hotplug related.
>
> On 2015/6/2 14:36, Jiang Liu wrote:
> > The dmaengine core assumes that async DMA devices will only be removed
> > when they not used anymore, or it assumes dma_async_device_unregister()
> > will only be called by dma driver exit routines. But this assumption is
> > not true for the IOAT driver, which calls dma_async_device_unregister()
> > from ioat_remove(). So current IOAT driver doesn't support device
> > hot-removal because it may cause system crash to hot-remove an inuse
> > IOAT device.
> >
> > To support CPU socket hot-removal, all PCI devices, including IOAT
> > devices embedded in the socket, will be hot-removed. The idea solution
> > is to enhance the dmaengine core and IOAT driver to support hot-removal,
> > but that's too hard.
> >
> > This patch implements a hack to disable IOAT devices under hotplug-capable
> > CPU socket so it won't break socket hot-removal.
> >
So below looks okay though I wonder how hard would it be to fix hot unplug ?
--
~Vinod
> > Signed-off-by: Jiang Liu <[email protected]>
> > ---
> > drivers/dma/ioat/pci.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
> > index 76f0dc688a19..3b8c9b03f4b3 100644
> > --- a/drivers/dma/ioat/pci.c
> > +++ b/drivers/dma/ioat/pci.c
> > @@ -27,6 +27,7 @@
> > #include <linux/interrupt.h>
> > #include <linux/dca.h>
> > #include <linux/slab.h>
> > +#include <linux/acpi.h>
> > #include "dma.h"
> > #include "dma_v2.h"
> > #include "registers.h"
> > @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
> > return d;
> > }
> >
> > +/*
> > + * The dmaengine core assumes that async DMA devices will only be removed
> > + * when they not used anymore, or it assumes dma_async_device_unregister()
> > + * will only be called by dma driver exit routines. But this assumption is
> > + * not true for the IOAT driver, which calls dma_async_device_unregister()
> > + * from ioat_remove(). So current IOAT driver doesn't support device
> > + * hot-removal because it may cause system crash to hot-remove inuse IOAT
> > + * devices.
> > + *
> > + * This is a hack to disable IOAT devices under ejectable PCI host bridge
> > + * so it won't break PCI host bridge hot-removal.
> > + */
> > +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
> > +{
> > +#ifdef CONFIG_ACPI
> > + struct pci_bus *bus = pdev->bus;
> > + struct acpi_device *adev;
> > +
> > + while (bus->parent)
> > + bus = bus->parent;
> > + for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
> > + if (adev->flags.ejectable)
> > + return true;
> > +#endif
> > +
> > + return false;
> > +}
> > +
> > static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > {
> > void __iomem * const *iomap;
> > @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > struct ioatdma_device *device;
> > int err;
> >
> > + if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
> > + dev_dbg(&pdev->dev, "ignore ejectable IOAT device.\n");
> > + return -ENODEV;
> > + }
> > +
> > err = pcim_enable_device(pdev);
> > if (err)
> > return err;
> >
--
On 2015/6/8 18:42, Vinod Koul wrote:
> On Tue, Jun 02, 2015 at 02:37:31PM +0800, Jiang Liu wrote:
>> Ccing Rafael, it's ACPI hotplug related.
>>
>> On 2015/6/2 14:36, Jiang Liu wrote:
>>> The dmaengine core assumes that async DMA devices will only be removed
>>> when they not used anymore, or it assumes dma_async_device_unregister()
>>> will only be called by dma driver exit routines. But this assumption is
>>> not true for the IOAT driver, which calls dma_async_device_unregister()
>>> from ioat_remove(). So current IOAT driver doesn't support device
>>> hot-removal because it may cause system crash to hot-remove an inuse
>>> IOAT device.
>>>
>>> To support CPU socket hot-removal, all PCI devices, including IOAT
>>> devices embedded in the socket, will be hot-removed. The idea solution
>>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
>>> but that's too hard.
>>>
>>> This patch implements a hack to disable IOAT devices under hotplug-capable
>>> CPU socket so it won't break socket hot-removal.
>>>
> So below looks okay though I wonder how hard would it be to fix hot unplug ?
Hi Vinod,
Thanks for review. About three years ago I worked out a
patch set to enhance the dmaengine core and ioat device driver to
support hot-removal. But it has been rejected due to concerns about
performance penalty caused by usage tracking.
To support hot-removal, we need to track dma channel usage
and a way to reclaim dma channels when hot-removing. This may cause
sensible performance penalty. Recently I have tried again but still
haven't find a way to support hot-removal. So eventually I suggest
to disable IOAT device on hot-plug capable systems.
Thanks!
Gerry
On Mon, Jun 08, 2015 at 07:44:43PM +0800, Jiang Liu wrote:
> On 2015/6/8 18:42, Vinod Koul wrote:
> > On Tue, Jun 02, 2015 at 02:37:31PM +0800, Jiang Liu wrote:
> >> Ccing Rafael, it's ACPI hotplug related.
> >>
> >> On 2015/6/2 14:36, Jiang Liu wrote:
> >>> The dmaengine core assumes that async DMA devices will only be removed
> >>> when they not used anymore, or it assumes dma_async_device_unregister()
> >>> will only be called by dma driver exit routines. But this assumption is
> >>> not true for the IOAT driver, which calls dma_async_device_unregister()
> >>> from ioat_remove(). So current IOAT driver doesn't support device
> >>> hot-removal because it may cause system crash to hot-remove an inuse
> >>> IOAT device.
> >>>
> >>> To support CPU socket hot-removal, all PCI devices, including IOAT
> >>> devices embedded in the socket, will be hot-removed. The idea solution
> >>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
> >>> but that's too hard.
> >>>
> >>> This patch implements a hack to disable IOAT devices under hotplug-capable
> >>> CPU socket so it won't break socket hot-removal.
> >>>
> > So below looks okay though I wonder how hard would it be to fix hot unplug ?
> Hi Vinod,
> Thanks for review. About three years ago I worked out a
> patch set to enhance the dmaengine core and ioat device driver to
> support hot-removal. But it has been rejected due to concerns about
> performance penalty caused by usage tracking.
> To support hot-removal, we need to track dma channel usage
> and a way to reclaim dma channels when hot-removing. This may cause
> sensible performance penalty. Recently I have tried again but still
> haven't find a way to support hot-removal. So eventually I suggest
> to disable IOAT device on hot-plug capable systems.
Or on a different mechanism, take the module reference on the channel
allocation and release it one channel release.
That way we don't need to count and we ensure dmaengine module is removed
only when users have stopped using the device...
--
~Vinod
On 2015/6/8 23:48, Vinod Koul wrote:
> On Mon, Jun 08, 2015 at 07:44:43PM +0800, Jiang Liu wrote:
>> On 2015/6/8 18:42, Vinod Koul wrote:
>>> On Tue, Jun 02, 2015 at 02:37:31PM +0800, Jiang Liu wrote:
>>>> Ccing Rafael, it's ACPI hotplug related.
>>>>
>>>> On 2015/6/2 14:36, Jiang Liu wrote:
>>>>> The dmaengine core assumes that async DMA devices will only be removed
>>>>> when they not used anymore, or it assumes dma_async_device_unregister()
>>>>> will only be called by dma driver exit routines. But this assumption is
>>>>> not true for the IOAT driver, which calls dma_async_device_unregister()
>>>>> from ioat_remove(). So current IOAT driver doesn't support device
>>>>> hot-removal because it may cause system crash to hot-remove an inuse
>>>>> IOAT device.
>>>>>
>>>>> To support CPU socket hot-removal, all PCI devices, including IOAT
>>>>> devices embedded in the socket, will be hot-removed. The idea solution
>>>>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
>>>>> but that's too hard.
>>>>>
>>>>> This patch implements a hack to disable IOAT devices under hotplug-capable
>>>>> CPU socket so it won't break socket hot-removal.
>>>>>
>>> So below looks okay though I wonder how hard would it be to fix hot unplug ?
>> Hi Vinod,
>> Thanks for review. About three years ago I worked out a
>> patch set to enhance the dmaengine core and ioat device driver to
>> support hot-removal. But it has been rejected due to concerns about
>> performance penalty caused by usage tracking.
>> To support hot-removal, we need to track dma channel usage
>> and a way to reclaim dma channels when hot-removing. This may cause
>> sensible performance penalty. Recently I have tried again but still
>> haven't find a way to support hot-removal. So eventually I suggest
>> to disable IOAT device on hot-plug capable systems.
>
> Or on a different mechanism, take the module reference on the channel
> allocation and release it one channel release.
>
> That way we don't need to count and we ensure dmaengine module is removed
> only when users have stopped using the device...
Hi Vinod,
The main trouble is caused by the fact that dmaengine use a
global reference count dmaengine_ref_count. Once DMA clients
increased the global reference count, they assume all DMA channels
won't go away and directly get DMA channel from the channel_table[]
table without increasing reference count on individual channel.
If we try to enable per-channel reference count, it may cause
performance penalty.
Another issue is that a DMA channel could be used by any CPU,
so we can't guarantee DMA channel is free even if we have stopped all
PCI devices under the same PCI host bridge with the IOAT device.
And there's no interface to reclaim channels from CPU or other DMA
clients yet.
So based on these factors, we suggest to disable IOAT devices
on hot-pluggable socket.
Thanks!
Gerry
On Mon, Jun 8, 2015 at 8:48 AM, Vinod Koul <[email protected]> wrote:
> On Mon, Jun 08, 2015 at 07:44:43PM +0800, Jiang Liu wrote:
>> On 2015/6/8 18:42, Vinod Koul wrote:
>> > On Tue, Jun 02, 2015 at 02:37:31PM +0800, Jiang Liu wrote:
>> >> Ccing Rafael, it's ACPI hotplug related.
>> >>
>> >> On 2015/6/2 14:36, Jiang Liu wrote:
>> >>> The dmaengine core assumes that async DMA devices will only be removed
>> >>> when they not used anymore, or it assumes dma_async_device_unregister()
>> >>> will only be called by dma driver exit routines. But this assumption is
>> >>> not true for the IOAT driver, which calls dma_async_device_unregister()
>> >>> from ioat_remove(). So current IOAT driver doesn't support device
>> >>> hot-removal because it may cause system crash to hot-remove an inuse
>> >>> IOAT device.
>> >>>
>> >>> To support CPU socket hot-removal, all PCI devices, including IOAT
>> >>> devices embedded in the socket, will be hot-removed. The idea solution
>> >>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
>> >>> but that's too hard.
>> >>>
>> >>> This patch implements a hack to disable IOAT devices under hotplug-capable
>> >>> CPU socket so it won't break socket hot-removal.
>> >>>
>> > So below looks okay though I wonder how hard would it be to fix hot unplug ?
>> Hi Vinod,
>> Thanks for review. About three years ago I worked out a
>> patch set to enhance the dmaengine core and ioat device driver to
>> support hot-removal. But it has been rejected due to concerns about
>> performance penalty caused by usage tracking.
>> To support hot-removal, we need to track dma channel usage
>> and a way to reclaim dma channels when hot-removing. This may cause
>> sensible performance penalty. Recently I have tried again but still
>> haven't find a way to support hot-removal. So eventually I suggest
>> to disable IOAT device on hot-plug capable systems.
>
> Or on a different mechanism, take the module reference on the channel
> allocation and release it one channel release.
>
> That way we don't need to count and we ensure dmaengine module is removed
> only when users have stopped using the device...
This was one of the first "features" of dmaengine I deleted. There's
no clean / reliable way to support general purpose dma-offload and
time bounded hot-removal. Multiple clients may be using a channel in
varied contexts so you both need to tell them to stop and wait for
them to acknowledge. On platforms with socket hotplug I would expect
the cpu to almost always be faster than an ioatdma offload. So, fwiw,
I think hotplug capability is more useful to the platform than ioatdma
offload.
Hi Dave,
Gentle Ping:) Any suggestion about this patch?
Thanks!
Gerry
On 2015/6/2 14:36, Jiang Liu wrote:
> The dmaengine core assumes that async DMA devices will only be removed
> when they not used anymore, or it assumes dma_async_device_unregister()
> will only be called by dma driver exit routines. But this assumption is
> not true for the IOAT driver, which calls dma_async_device_unregister()
> from ioat_remove(). So current IOAT driver doesn't support device
> hot-removal because it may cause system crash to hot-remove an inuse
> IOAT device.
>
> To support CPU socket hot-removal, all PCI devices, including IOAT
> devices embedded in the socket, will be hot-removed. The idea solution
> is to enhance the dmaengine core and IOAT driver to support hot-removal,
> but that's too hard.
>
> This patch implements a hack to disable IOAT devices under hotplug-capable
> CPU socket so it won't break socket hot-removal.
>
> Signed-off-by: Jiang Liu <[email protected]>
> ---
> drivers/dma/ioat/pci.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
> index 76f0dc688a19..3b8c9b03f4b3 100644
> --- a/drivers/dma/ioat/pci.c
> +++ b/drivers/dma/ioat/pci.c
> @@ -27,6 +27,7 @@
> #include <linux/interrupt.h>
> #include <linux/dca.h>
> #include <linux/slab.h>
> +#include <linux/acpi.h>
> #include "dma.h"
> #include "dma_v2.h"
> #include "registers.h"
> @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
> return d;
> }
>
> +/*
> + * The dmaengine core assumes that async DMA devices will only be removed
> + * when they not used anymore, or it assumes dma_async_device_unregister()
> + * will only be called by dma driver exit routines. But this assumption is
> + * not true for the IOAT driver, which calls dma_async_device_unregister()
> + * from ioat_remove(). So current IOAT driver doesn't support device
> + * hot-removal because it may cause system crash to hot-remove inuse IOAT
> + * devices.
> + *
> + * This is a hack to disable IOAT devices under ejectable PCI host bridge
> + * so it won't break PCI host bridge hot-removal.
> + */
> +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
> +{
> +#ifdef CONFIG_ACPI
> + struct pci_bus *bus = pdev->bus;
> + struct acpi_device *adev;
> +
> + while (bus->parent)
> + bus = bus->parent;
> + for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
> + if (adev->flags.ejectable)
> + return true;
> +#endif
> +
> + return false;
> +}
> +
> static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> {
> void __iomem * const *iomap;
> @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> struct ioatdma_device *device;
> int err;
>
> + if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
> + dev_dbg(&pdev->dev, "ignore ejectable IOAT device.\n");
> + return -ENODEV;
> + }
> +
> err = pcim_enable_device(pdev);
> if (err)
> return err;
>
> On Jun 28, 2015, at 7:14 PM, Jiang Liu <[email protected]> wrote:
>
> Hi Dave,
> Gentle Ping:) Any suggestion about this patch?
> Thanks!
> Gerry
I'm fine with it if Dan has no objections.
>> On 2015/6/2 14:36, Jiang Liu wrote:
>> The dmaengine core assumes that async DMA devices will only be removed
>> when they not used anymore, or it assumes dma_async_device_unregister()
>> will only be called by dma driver exit routines. But this assumption is
>> not true for the IOAT driver, which calls dma_async_device_unregister()
>> from ioat_remove(). So current IOAT driver doesn't support device
>> hot-removal because it may cause system crash to hot-remove an inuse
>> IOAT device.
>>
>> To support CPU socket hot-removal, all PCI devices, including IOAT
>> devices embedded in the socket, will be hot-removed. The idea solution
>> is to enhance the dmaengine core and IOAT driver to support hot-removal,
>> but that's too hard.
>>
>> This patch implements a hack to disable IOAT devices under hotplug-capable
>> CPU socket so it won't break socket hot-removal.
>>
>> Signed-off-by: Jiang Liu <[email protected]>
>> ---
>> drivers/dma/ioat/pci.c | 34 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
>> index 76f0dc688a19..3b8c9b03f4b3 100644
>> --- a/drivers/dma/ioat/pci.c
>> +++ b/drivers/dma/ioat/pci.c
>> @@ -27,6 +27,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/dca.h>
>> #include <linux/slab.h>
>> +#include <linux/acpi.h>
>> #include "dma.h"
>> #include "dma_v2.h"
>> #include "registers.h"
>> @@ -148,6 +149,34 @@ alloc_ioatdma(struct pci_dev *pdev, void __iomem *iobase)
>> return d;
>> }
>>
>> +/*
>> + * The dmaengine core assumes that async DMA devices will only be removed
>> + * when they not used anymore, or it assumes dma_async_device_unregister()
>> + * will only be called by dma driver exit routines. But this assumption is
>> + * not true for the IOAT driver, which calls dma_async_device_unregister()
>> + * from ioat_remove(). So current IOAT driver doesn't support device
>> + * hot-removal because it may cause system crash to hot-remove inuse IOAT
>> + * devices.
>> + *
>> + * This is a hack to disable IOAT devices under ejectable PCI host bridge
>> + * so it won't break PCI host bridge hot-removal.
>> + */
>> +static bool ioat_pci_has_ejectable_acpi_ancestor(struct pci_dev *pdev)
>> +{
>> +#ifdef CONFIG_ACPI
>> + struct pci_bus *bus = pdev->bus;
>> + struct acpi_device *adev;
>> +
>> + while (bus->parent)
>> + bus = bus->parent;
>> + for (adev = ACPI_COMPANION(bus->bridge); adev; adev = adev->parent)
>> + if (adev->flags.ejectable)
>> + return true;
>> +#endif
>> +
>> + return false;
>> +}
>> +
>> static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>> {
>> void __iomem * const *iomap;
>> @@ -155,6 +184,11 @@ static int ioat_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>> struct ioatdma_device *device;
>> int err;
>>
>> + if (ioat_pci_has_ejectable_acpi_ancestor(pdev)) {
>> + dev_dbg(&pdev->dev, "ignore ejectable IOAT device.\n");
>> + return -ENODEV;
>> + }
>> +
>> err = pcim_enable_device(pdev);
>> if (err)
>> return err;
>>