From: David Miller <davem@davemloft.net>
To: dan.j.williams@intel.com
Cc: anemo@mba.ocn.ne.jp, maciej.sosnowski@intel.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] net_dma: call dmaengine_get only if NET_DMA enabled
Date: Fri, 06 Feb 2009 14:09:12 -0800 (PST) [thread overview]
Message-ID: <20090206.140912.40800913.davem@davemloft.net> (raw)
In-Reply-To: <e9c3a7c20902061315n7184c55ck7fcaa2c519a035d4@mail.gmail.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Fri, 6 Feb 2009 14:15:02 -0700
> [ please cc netdev on net_dma patches ]
>
> On Fri, Feb 6, 2009 at 9:02 AM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> > The commit 649274d993212e7c23c0cb734572c2311c200872 ("net_dma:
> > acquire/release dma channels on ifup/ifdown") added unconditional call
> > of dmaengine_get() to net_dma. The API should be called only if
> > NET_DMA was enabled.
> >
> > Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
>
> I was looking to avoid ifdefs in this path by making
> dmaengine_{get,put} a nop in the DMAENGINE=n case. However, the
> current code with DMAENGINE=y NET_DMA=n will pin channels even though
> the network stack is not using them.
I don't want to apply this patch at all.
What is the purpose of keeping the ugly ifdefs in dmaengine.h if we're
just going to pollute the networking code with the ifdefs anyways?
Make the NOP versions in linux/dmaengine.h actually work.
The NET_DMA stuff is the one thing which is polluting up the networking
stack with ugly ifdefs, I'm not adding new ones.
next prev parent reply other threads:[~2009-02-06 22:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-06 16:02 [PATCH] net_dma: call dmaengine_get only if NET_DMA enabled Atsushi Nemoto
2009-02-06 21:15 ` Dan Williams
2009-02-06 22:09 ` David Miller [this message]
2009-02-06 22:52 ` Dan Williams
2009-02-07 3:29 ` David Miller
2009-02-07 5:55 ` David Miller
2009-02-07 6:03 ` Dan Williams
2009-02-07 6:05 ` David Miller
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=20090206.140912.40800913.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=anemo@mba.ocn.ne.jp \
--cc=dan.j.williams@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.sosnowski@intel.com \
--cc=netdev@vger.kernel.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.