On Mon, 25 Jan 2016 12:41:50 +0100,
Mark Brown wrote:
>
> On Mon, Jan 25, 2016 at 10:29:54AM +0100, Takashi Iwai wrote:
> > Stephen Rothwell wrote:
>
> > > diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> > > index 50693c867e71..ee5f36b9c787 100644
> > > --- a/sound/soc/codecs/Kconfig
> > > +++ b/sound/soc/codecs/Kconfig
> > > @@ -13,6 +13,7 @@ menu "CODEC drivers"
> > > config SND_SOC_ALL_CODECS
> > > tristate "Build all ASoC CODEC drivers"
> > > depends on COMPILE_TEST
> > > + depends on !PPC
> > > select SND_SOC_88PM860X if MFD_88PM860X
> > > select SND_SOC_L3
> > > select SND_SOC_AB8500_CODEC if ABX500_CORE
>
> > Suppressing this whole is an overreaction, IMO. It should suffice
> > just to disable compile-testing Intel driver.
>
> Please send patches and reports to maintainers :( I agree that this is
> an absurdly wide change.
>
> > diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig
> > index 803f95e40679..d854cd66e090 100644
> > --- a/sound/soc/intel/Kconfig
> > +++ b/sound/soc/intel/Kconfig
> > @@ -31,6 +31,8 @@ config SND_SOC_INTEL_SST
> > tristate
> > select SND_SOC_INTEL_SST_ACPI if ACPI
> > depends on (X86 || COMPILE_TEST)
> > + # FIXME: a part of compress API is broken for PPC
> > + depends on !PPC
>
> Why is an Intel CPU thing being enabled by SND_SOC_ALL_CODECS? I'm also
> unclear why this will help when we're selecting in the drivers so their
> dependencies will be ignored.
Yeah, obviously papering over a wrong place.
In anyway, thinking of this workaround again, I don't think it being
the best way. The easier and safer workaround is to just avoid the
corresponding ioctl being handled. The untested patch is attached
below.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai@xxxxxxx>
Subject: [PATCH] ALSA: compress: Disable GET_CODEC_CAPS ioctl for some
architectures
Some architectures like PowerPC can handle the maximum struct size in
an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by
SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This
problem was revealed recently by a powerpc change, as it's now treated
as a fatal build error.
This patch is a workaround for that: for architectures with less than
14 bit ioctl struct size, get rid of the handling of the relevant
ioctl. We should provide an alternative equivalent ioctl code later,
but for now just paper over it. Luckily, the compress API hasn't been
used on such architectures, so the impact must be effectively zero.
Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
---
sound/core/compress_offload.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index 18b8dc45bb8f..36b0083fd9f4 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -46,6 +46,13 @@
#include <sound/compress_offload.h>
#include <sound/compress_driver.h>
+/* FIXME: struct snd_compr_codec_caps overflows the ioctl bit size for some
+ * architectures, so we need to disable the relevant ioctls.
+ */
+#if _IOC_SIZEBITS < 13
+#define COMPR_CODEC_CAPS_OVERFLOW
+#endif
+
/* TODO:
* - add substream support for multiple devices in case of
* SND_DYNAMIC_MINORS is not used
@@ -440,6 +447,7 @@ out:
return retval;
}
+#ifndef COMPR_CODEC_CAPS_OVERFLOW
static int
snd_compr_get_codec_caps(struct snd_compr_stream *stream, unsigned long arg)
{
@@ -463,6 +471,7 @@ out:
kfree(caps);
return retval;
}
+#endif /* !COMPR_CODEC_CAPS_OVERFLOW */
/* revisit this with snd_pcm_preallocate_xxx */
static int snd_compr_allocate_buffer(struct snd_compr_stream *stream,
@@ -801,9 +810,11 @@ static long snd_compr_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
retval = snd_compr_get_caps(stream, arg);
break;
+#ifndef COMPR_CODEC_CAPS_OVERFLOW
case _IOC_NR(SNDRV_COMPRESS_GET_CODEC_CAPS):
retval = snd_compr_get_codec_caps(stream, arg);
break;
+#endif
case _IOC_NR(SNDRV_COMPRESS_SET_PARAMS):
retval = snd_compr_set_params(stream, arg);
break;
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
