[PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static

[PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static

[kbuild test robot]

sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 atlas7-iacc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sirf/atlas7-iacc.c b/sound/soc/sirf/atlas7-iacc.c
index ca17e90..a359d8b 100644
--- a/sound/soc/sirf/atlas7-iacc.c
+++ b/sound/soc/sirf/atlas7-iacc.c
@@ -165,7 +165,7 @@ static int atlas7_iacc_trigger(struct snd_pcm_substream *substream,
 	return 0;
 }
 
-struct snd_soc_dai_ops atlas7_iacc_dai_ops = {
+static struct snd_soc_dai_ops atlas7_iacc_dai_ops = {
 	.hw_params = atlas7_iacc_hw_params,
 	.trigger = atlas7_iacc_trigger,
 };

[baohua:sirf-3.18 2573/2782] sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux sirf-3.18
head:   d61ca44a1d96f134d35d31522ca8efb19a6e1451
commit: 81aba96393135459ac811ce78fe8f91a8b767b82 [2573/2782] ASoC: sirf: atlas7: Add internal audio codec controller driver
reproduce:
  # apt-get install sparse
  git checkout 81aba96393135459ac811ce78fe8f91a8b767b82
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?
   sound/soc/sirf/atlas7-iacc.c:482:27: sparse: incorrect type in initializer (incompatible argument 4 (different address spaces))
   sound/soc/sirf/atlas7-iacc.c:482:27:    expected int ( *copy )( ... )
   sound/soc/sirf/atlas7-iacc.c:482:27:    got int ( static [toplevel] *<noident> )( ... )

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild                 Intel Corporation

[PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static

[Mark Brown]

On Fri, Feb 06, 2015 at 01:03:52AM +0800, kbuild test robot wrote:
> sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?

This file isn't in an upstream tree, should this patch have been sent
upstream (I suspect non-upstream trees may need a bit of filtering in
the scripts)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150205/11b82af1/attachment-0001.sig>

[alsa-devel] [PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static

[Barry Song]

2015-02-06 1:11 GMT+08:00 Mark Brown <broonie@kernel.org>:
> On Fri, Feb 06, 2015 at 01:03:52AM +0800, kbuild test robot wrote:
>> sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?
>
> This file isn't in an upstream tree, should this patch have been sent
> upstream (I suspect non-upstream trees may need a bit of filtering in
> the scripts)?

the file is new and under developing. so no patch for it yet. is it
possible to modify kbuild script?

>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

-barry

[PATCH baohua] ASoC: sirf: atlas7: atlas7_iacc_dai_ops can be static

[Fengguang Wu]

On Thu, Feb 05, 2015 at 05:11:59PM +0000, Mark Brown wrote:
> On Fri, Feb 06, 2015 at 01:03:52AM +0800, kbuild test robot wrote:
> > sound/soc/sirf/atlas7-iacc.c:168:24: sparse: symbol 'atlas7_iacc_dai_ops' was not declared. Should it be static?
> 
> This file isn't in an upstream tree, should this patch have been sent
> upstream (I suspect non-upstream trees may need a bit of filtering in
> the scripts)?

Good point! I just added some tests trying to avoid this, which should
be much better, but nevertheless not complete enough to cover all cases.
Please help point out inadequate cases when you come across them in future!

Thanks,
Fengguang