From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH] powerpc: dma-mapping: Return dma_direct_ops variable when dev == NULL
Date: Tue, 14 Jan 2014 21:14:06 +1100 [thread overview]
Message-ID: <1389694446.6933.14.camel@pasglop> (raw)
In-Reply-To: <1389692656-27758-1-git-send-email-Chunhe.Lan@freescale.com>
On Tue, 2014-01-14 at 17:44 +0800, Chunhe Lan wrote:
> Without this patch, kind of below error will be dumped if
> 'insmod ixgbevf.ko' is executed:
>
> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function
> Network Driver - version 2.7.12-k
> ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
> ixgbevf 0000:01:10.0: enabling device (0000 -> 0002)
> ixgbevf 0000:01:10.0: No usable DMA configuration, aborting
> ixgbevf: probe of 0000:01:10.0 failed with error -5
> ......
> ......
That's not right. The DMA ops must be set properly for the VF somewhere
in the arch code instead. When creating VFs, is there a hook allowing
the arch to fix things up ?
(Also adding linux-pci on CC)
Ben.
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Tested-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index e27e9ad..b8c10de 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -84,10 +84,15 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> * only ISA DMA device we support is the floppy and we have a hack
> * in the floppy driver directly to get a device for us.
> */
> - if (unlikely(dev == NULL))
> - return NULL;
> -
> - return dev->archdata.dma_ops;
> + if (dev && dev->archdata.dma_ops)
> + return dev->archdata.dma_ops;
> + /*
> + * In some cases (for example, use the Intel(R) 10 Gigabit PCI
> + * expression Virtual Function Network Driver -- ixgbevf.ko),
> + * their value of dev is the NULL. If return NULL, the driver is
> + * aborting. So return dma_direct_ops variable when dev == NULL.
> + */
> + return &dma_direct_ops;
> }
>
> static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: dma-mapping: Return dma_direct_ops variable when dev == NULL
Date: Tue, 14 Jan 2014 21:14:06 +1100 [thread overview]
Message-ID: <1389694446.6933.14.camel@pasglop> (raw)
In-Reply-To: <1389692656-27758-1-git-send-email-Chunhe.Lan@freescale.com>
On Tue, 2014-01-14 at 17:44 +0800, Chunhe Lan wrote:
> Without this patch, kind of below error will be dumped if
> 'insmod ixgbevf.ko' is executed:
>
> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function
> Network Driver - version 2.7.12-k
> ixgbevf: Copyright (c) 2009 - 2012 Intel Corporation.
> ixgbevf 0000:01:10.0: enabling device (0000 -> 0002)
> ixgbevf 0000:01:10.0: No usable DMA configuration, aborting
> ixgbevf: probe of 0000:01:10.0 failed with error -5
> ......
> ......
That's not right. The DMA ops must be set properly for the VF somewhere
in the arch code instead. When creating VFs, is there a hook allowing
the arch to fix things up ?
(Also adding linux-pci on CC)
Ben.
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Tested-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index e27e9ad..b8c10de 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -84,10 +84,15 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> * only ISA DMA device we support is the floppy and we have a hack
> * in the floppy driver directly to get a device for us.
> */
> - if (unlikely(dev == NULL))
> - return NULL;
> -
> - return dev->archdata.dma_ops;
> + if (dev && dev->archdata.dma_ops)
> + return dev->archdata.dma_ops;
> + /*
> + * In some cases (for example, use the Intel(R) 10 Gigabit PCI
> + * expression Virtual Function Network Driver -- ixgbevf.ko),
> + * their value of dev is the NULL. If return NULL, the driver is
> + * aborting. So return dma_direct_ops variable when dev == NULL.
> + */
> + return &dma_direct_ops;
> }
>
> static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
next prev parent reply other threads:[~2014-01-14 10:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 9:44 [PATCH] powerpc: dma-mapping: Return dma_direct_ops variable when dev == NULL Chunhe Lan
2014-01-14 10:14 ` Benjamin Herrenschmidt [this message]
2014-01-14 10:14 ` Benjamin Herrenschmidt
2014-01-15 3:36 ` Chunhe Lan
2014-01-15 3:36 ` Chunhe Lan
2014-01-15 3:47 ` Benjamin Herrenschmidt
2014-01-15 3:47 ` Benjamin Herrenschmidt
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=1389694446.6933.14.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Chunhe.Lan@freescale.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.