linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).