From: Chen Gang <gang.chen.5i5j@gmail.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Liqin Chen <liqin.linux@gmail.com>,
Lennox Wu <lennox.wu@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH] drivers: firewire: Let several sub-modules depend on HAS_DMA
Date: Sun, 13 Jul 2014 18:19:40 +0800 [thread overview]
Message-ID: <53C25D3C.9070707@gmail.com> (raw)
In-Reply-To: <20140713104238.7214db0f@kant>
On 07/13/2014 04:42 PM, Stefan Richter wrote:
> On Jul 13 Chen Gang wrote:
>>
>> config FIREWIRE_OHCI
>> tristate "OHCI-1394 controllers"
>> - depends on PCI && FIREWIRE && MMU
>> + depends on PCI && FIREWIRE && MMU && HAS_DMA
>> help
>> Enable this driver if you have a FireWire controller based
>> on the OHCI specification. For all practical purposes, this
>
> As far as I understand, architecture configuration files shall already
> ensure that CONFIG_PCI is not enabled if !CONFIG_HAS_DMA. If so, this
> part can be omitted. Or am I mistaken?
>
Yeah, this part can be omitted, what you said is OK to me. FIREWIER_OHCI
need not append additional "depends on HAS_DMA".
>> @@ -45,7 +45,7 @@ config FIREWIRE_SBP2
>>
>> config FIREWIRE_NET
>> tristate "IP networking over 1394"
>> - depends on FIREWIRE && INET
>> + depends on FIREWIRE && INET && HAS_DMA
>> help
>> This enables IPv4/IPv6 over IEEE 1394, providing IP connectivity
>> with other implementations of RFC 2734/3146 as found on several
>
> This is not completely necessary: firewire-net does not use DMA mapping
> APIs directly, it uses them only through firewire-core. Same with
> sound/firewire/* (a few audio device drivers) and with
> drivers/media/firewire/* (a DVB device driver) which you did not patch.
>
Yeah, thanks.
> So they could be *compiled* on architectures without HAS_DMA, they could
> just not be *used* (because firewire-core's isochronous DMA mapping
> functions would return errors, but more so because there are no IEEE 1394
> host bus adapters on these platforms in the first place. Actually Texas
> Instruments used to make a 1394 HBA chip with some sort of GPIO host
> interface instead of PCI interface, but Linux only has a driver for PCI
> HBAs.)
>
> But see below.
>
OK, thank you for your details information.
>
> All in all, I like the following approach better:
>
> Date: Wed, 9 Jul 2014 21:04:00 +0200
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> To: Stefan Richter <stefanr@s5r6.in-berlin.de>
> Cc: Jean Delvare <jdelvare@suse.de>, linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Geert Uytterhoeven <geert@linux-m68k.org>
> Subject: [PATCH] firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA
>
> Commit b3d681a4fc108f9653bbb44e4f4e72db2b8a5734 ("firewire: Use
> COMPILE_TEST for build testing") added COMPILE_TEST as an alternative
> dependency for the purpose of build testing the firewire core.
> However, this bypasses all other implicit dependencies assumed by PCI,
> like HAS_DMA.
>
> If NO_DMA=y:
>
> drivers/built-in.o: In function `fw_iso_buffer_destroy':
> (.text+0x36a096): undefined reference to `dma_unmap_page'
> drivers/built-in.o: In function `fw_iso_buffer_map_dma':
> (.text+0x36a164): undefined reference to `dma_map_page'
> drivers/built-in.o: In function `fw_iso_buffer_map_dma':
> (.text+0x36a172): undefined reference to `dma_mapping_error'
> drivers/built-in.o: In function `sbp2_send_management_orb':
> sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single'
> sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error'
> sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single'
> sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error'
> sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single'
> sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `sbp2_map_scatterlist':
> sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map'
> sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single'
> sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error'
> sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap'
> drivers/built-in.o: In function `sbp2_unmap_scatterlist':
> sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap'
> sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `complete_command_orb':
> sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `sbp2_scsi_queuecommand':
> sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single'
> sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error'
>
> Add an explicit dependency on HAS_DMA to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Jean Delvare <jdelvare@suse.de>
> ---
> drivers/firewire/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
> index 4199849e3758..145974f9662b 100644
> --- a/drivers/firewire/Kconfig
> +++ b/drivers/firewire/Kconfig
> @@ -1,4 +1,5 @@
> menu "IEEE 1394 (FireWire) support"
> + depends on HAS_DMA
> depends on PCI || COMPILE_TEST
> # firewire-core does not depend on PCI but is
> # not useful without PCI controller driver
>
> As a downside, this removes the ability to test-build the sound and DVB
> high-level 1394 drivers (and firewire-net) on !HAS_DMA architectures.
> But on the positive side, it is simpler. If there are no objections,
> I am going to commit Geert's fix.
>
What Geert has done (patch and comments) also sounds fine to me. Thank
you for all of your work.
Thanks.
--
Chen Gang
Open share and attitude like air water and life which God blessed
prev parent reply other threads:[~2014-07-13 10:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-13 3:06 [PATCH] drivers: firewire: Let several sub-modules depend on HAS_DMA Chen Gang
2014-07-13 8:42 ` Stefan Richter
2014-07-13 10:19 ` Chen Gang [this message]
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=53C25D3C.9070707@gmail.com \
--to=gang.chen.5i5j@gmail.com \
--cc=geert@linux-m68k.org \
--cc=jdelvare@suse.de \
--cc=lennox.wu@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=liqin.linux@gmail.com \
--cc=stefanr@s5r6.in-berlin.de \
/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).