December 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: ctl: allow TLV read operation for callback type of element in locked case
by Takashi Sakamoto 24 Dec '19

24 Dec '19

A design of ALSA control core allows applications to execute three operations for TLV feature; read, write and command. Furthermore, it allows driver developers to process the operations by two ways; allocated array or callback function. In the former, read operation is just allowed, thus developers uses the latter when device driver supports variety of models or the target model is expected to dynamically change information stored in TLV container. The core also allows applications to lock any element so that the other applications can't perform write operation to the element for element value and TLV information. When the element is locked, write and command operation for TLV information are prohibited as well as element value. Any read operation should be allowed in the case. At present, when an element has callback function for TLV information, TLV read operation returns EPERM if the element is locked. On the other hand, the read operation is success when an element has allocated array for TLV information. In both cases, read operation is success for element value expectedly. This commit fixes the bug. This change can be backported to v4.14 kernel or later. --- sound/core/control.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/core/control.c b/sound/core/control.c index 3fa1171dc1c2..49f3428dfacb 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -1398,8 +1398,9 @@ static int call_tlv_handler(struct snd_ctl_file *file, int op_flag, if (kctl->tlv.c == NULL) return -ENXIO; - /* When locked, this is unavailable. */ - if (vd->owner != NULL && vd->owner != file) + // Write and command operations are not allowed for locked element. + if (op_flag != SNDRV_CTL_TLV_OP_READ && + vd->owner != NULL && vd->owner != file) return -EPERM; return kctl->tlv.c(kctl, op_flag, size, buf); -- 2.20.1

3 5

[alsa-devel] [PATCH] xfer-opitons: Fix -Wformat=2 warnings
by Rosen Penev 24 Dec '19

24 Dec '19

Allows the compiler to check types. format string functions expect constant expressions, not constant variables. Signed-off-by: Rosen Penev <rosenp(a)gmail.com> --- axfer/xfer-options.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/axfer/xfer-options.c b/axfer/xfer-options.c index 3740b16..d4e5ff2 100644 --- a/axfer/xfer-options.c +++ b/axfer/xfer-options.c @@ -422,8 +422,6 @@ static int generate_path_with_suffix(struct xfer_context *xfer, const char *template, unsigned int index, const char *suffix) { - static const char *const single_format = "%s%s"; - static const char *const multiple_format = "%s-%i%s"; unsigned int len; len = strlen(template) + strlen(suffix) + 1; @@ -435,10 +433,10 @@ static int generate_path_with_suffix(struct xfer_context *xfer, return -ENOMEM; if (xfer->path_count == 1) { - snprintf(xfer->paths[index], len, single_format, template, + snprintf(xfer->paths[index], len, "%s%s", template, suffix); } else { - snprintf(xfer->paths[index], len, multiple_format, template, + snprintf(xfer->paths[index], len, "%s-%i%s", template, index, suffix); } @@ -449,8 +447,6 @@ static int generate_path_without_suffix(struct xfer_context *xfer, const char *template, unsigned int index, const char *suffix) { - static const char *const single_format = "%s"; - static const char *const multiple_format = "%s-%i"; unsigned int len; len = strlen(template) + 1; @@ -462,9 +458,9 @@ static int generate_path_without_suffix(struct xfer_context *xfer, return -ENOMEM; if (xfer->path_count == 1) { - snprintf(xfer->paths[index], len, single_format, template); + snprintf(xfer->paths[index], len, "%s", template); } else { - snprintf(xfer->paths[index], len, multiple_format, template, + snprintf(xfer->paths[index], len, "%s-%i", template, index); } -- 2.24.1

2 1

[alsa-devel] [PATCH] ALSA: hda - Apply sync-write workaround to old Intel platforms, too
by Takashi Iwai 23 Dec '19

23 Dec '19

Klaus Ethgen reported occasional high CPU usages in his system that seem caused by HD-audio driver. The perf output revealed that it's in the unsolicited event handling in the workqueue, and the problem seems triggered by some communication stall between the controller and the codec at the runtime or system resume. Actually a similar phenomenon was seen in the past for other Intel platforms, and we already applied the workaround to enforce sync-write for CORB/RIRB verbs for Skylake and newer chipsets (commit 2756d9143aa5 "ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Fortunately, the same workaround is applicable to the old chipset, and the experiment showed the positive effect. Based on the experiment result, this patch enables the sync-write workaround for all Intel chipsets. The only reason I hesitated to apply this workaround was about the possibly slightly higher CPU usage. But if the lack of sync causes a much severer problem even for quite old chip, we should think this would be necessary for all Intel chips. Reported-by: Klaus Ethgen <Klaus(a)ethgen.ch> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20191223171833.GA17053@chua Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f69c8de64bd6..5b92f290cbb0 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -282,12 +282,13 @@ enum { /* quirks for old Intel chipsets */ #define AZX_DCAPS_INTEL_ICH \ - (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE) + (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE |\ + AZX_DCAPS_SYNC_WRITE) /* quirks for Intel PCH */ #define AZX_DCAPS_INTEL_PCH_BASE \ (AZX_DCAPS_NO_ALIGN_BUFSIZE | AZX_DCAPS_COUNT_LPIB_DELAY |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) /* PCH up to IVB; no runtime PM; bind with i915 gfx */ #define AZX_DCAPS_INTEL_PCH_NOPM \ @@ -302,13 +303,13 @@ enum { #define AZX_DCAPS_INTEL_HASWELL \ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_COUNT_LPIB_DELAY |\ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) /* Broadwell HDMI can't use position buffer reliably, force to use LPIB */ #define AZX_DCAPS_INTEL_BROADWELL \ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_POSFIX_LPIB |\ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_COMPONENT |\ - AZX_DCAPS_SNOOP_TYPE(SCH)) + AZX_DCAPS_SNOOP_TYPE(SCH) | AZX_DCAPS_SYNC_WRITE) #define AZX_DCAPS_INTEL_BAYTRAIL \ (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_I915_COMPONENT) -- 2.16.4

1 0

[alsa-devel] CPU hook snd_hda_intel
by Klaus Ethgen 23 Dec '19

23 Dec '19

Hello, Please keep me in Cc when you answer as I am not subscribed to the list. I use the most current kernel 5.4.1 (but I did have that problem since several 5.x versions) on gentoo on a X61s Lenovo laptop. What I see is that from time to time one CPU is constantly working and draining my battery with a process kworker/*-events. Today I was able to identify the source of the problem. The module snd-hda-intel seems to produce that load. When I unload the module, the CPU hook is gone. Even if I load it again, I have a good change to solve the problem. It also helps often to put the laptop to sleep and waking it up again. My relevant dmesg part is: [ 7.186766] snd_hda_intel 0000:00:1b.0: probe_mask set to 0x1 for device 17aa:20ac [ 7.563277] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker [ 7.563281] snd_hda_codec_generic hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 7.563284] snd_hda_codec_generic hdaudioC0D0: hp_outs=1 (0x11/0x0/0x0/0x0/0x0) [ 7.563286] snd_hda_codec_generic hdaudioC0D0: mono: mono_out=0x0 [ 7.563288] snd_hda_codec_generic hdaudioC0D0: inputs: [ 7.563292] snd_hda_codec_generic hdaudioC0D0: Internal Mic=0x15 [ 7.563294] snd_hda_codec_generic hdaudioC0D0: Mic=0x14 [ 7.563297] snd_hda_codec_generic hdaudioC0D0: Dock Mic=0x1c For reference I attach my kernel config to this mail. I am not sure if it is needed but better give as much as informations that I have. So please, if you have any idea how to narrow that problem or even solve it, help would be appreciated. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <Klaus(a)Ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C

2 16

[alsa-devel] [PATCH alsa-lib, alsa-plugins] Update the attributes.m4 macro file from xine
by David Ward 23 Dec '19

23 Dec '19

This file was imported from the xine project. Update it to the current revision, which resolves the "no AC_LANG_SOURCE call detected in body" warnings with Autoconf 2.68 or later. Signed-off-by: David Ward <david.ward(a)ll.mit.edu> --- m4/attributes.m4 | 33 ++++++++++++++++++++------------- 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/m4/attributes.m4 b/m4/attributes.m4 index e86456a..3d9c256 100644 --- a/m4/attributes.m4 +++ b/m4/attributes.m4 @@ -1,6 +1,6 @@ dnl Macros to check the presence of generic (non-typed) symbols. -dnl Copyright (c) 2006-2007 Diego Pettenò <flameeyes(a)gmail.com> -dnl Copyright (c) 2006-2007 xine project +dnl Copyright (c) 2006-2008 Diego Pettenò <flameeyes(a)gmail.com> +dnl Copyright (c) 2006-2008 xine project dnl dnl This program is free software; you can redistribute it and/or modify dnl it under the terms of the GNU General Public License as published by @@ -25,7 +25,7 @@ dnl License when using or distributing such scripts, even though portions dnl of the text of the Macro appear in them. The GNU General Public dnl License (GPL) does govern all other use of the material that dnl constitutes the Autoconf Macro. -dnl +dnl dnl This special exception to the GPL applies to versions of the dnl Autoconf Macro released by this project. When you make and dnl distribute a modified version of the Autoconf Macro, you may extend @@ -39,7 +39,7 @@ AC_DEFUN([CC_CHECK_CFLAGS_SILENT], [ AC_CACHE_VAL(AS_TR_SH([cc_cv_cflags_$1]), [ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $1" - AC_COMPILE_IFELSE([int a;], + AC_COMPILE_IFELSE([AC_LANG_SOURCE([int a;])], [eval "AS_TR_SH([cc_cv_cflags_$1])='yes'"], [eval "AS_TR_SH([cc_cv_cflags_$1])='no'"]) CFLAGS="$ac_save_CFLAGS" @@ -71,7 +71,7 @@ AC_DEFUN([CC_CHECK_CFLAG_APPEND], [ ) AS_IF([eval test x$]AS_TR_SH([cc_cv_cflags_$1])[ = xyes], - [CFLAGS="$CFLAGS $1"; $2], [$3]) + [CFLAGS="$CFLAGS $1"; DEBUG_CFLAGS="$DEBUG_CFLAGS $1"; $2], [$3]) ]) dnl CC_CHECK_CFLAGS_APPEND([FLAG1 FLAG2], [action-if-found], [action-if-not]) @@ -89,7 +89,7 @@ AC_DEFUN([CC_CHECK_LDFLAGS], [ AS_TR_SH([cc_cv_ldflags_$1]), [ac_save_LDFLAGS="$LDFLAGS" LDFLAGS="$LDFLAGS $1" - AC_LINK_IFELSE([int main() { return 1; }], + AC_LINK_IFELSE([AC_LANG_SOURCE([int main() { return 1; }])], [eval "AS_TR_SH([cc_cv_ldflags_$1])='yes'"], [eval "AS_TR_SH([cc_cv_ldflags_$1])="]) LDFLAGS="$ac_save_LDFLAGS" @@ -109,14 +109,21 @@ AC_DEFUN([CC_NOUNDEFINED], [ dnl FreeBSD (et al.) does not complete linking for shared objects when pthreads dnl are requested, as different implementations are present; to avoid problems dnl use -Wl,-z,defs only for those platform not behaving this way. - *-freebsd*) ;; + dnl + dnl MinGW platforms: for libraries required -no-undefined, + dnl use it only for libraries in mingw32-w64 + + *-freebsd* | *-openbsd*) ;; + *-mingw*) + LDFLAGS_NOUNDEFINED="-no-undefined" + ;; *) dnl First of all check for the --no-undefined variant of GNU ld. This allows dnl for a much more readable commandline, so that people can understand what dnl it does without going to look for what the heck -z defs does. - for possible_flags in "-Wl,--no-undefined" "-Wl,-z,defs"; do + for possible_flags in "-Wl,--no-undefined" "-Wl,-z,defs"; do CC_CHECK_LDFLAGS([$possible_flags], [LDFLAGS_NOUNDEFINED="$possible_flags"]) - break + if test "x$LDFLAGS_NOUNDEFINED" = "x"; then break; fi done ;; esac @@ -147,7 +154,7 @@ AC_DEFUN([CC_CHECK_ATTRIBUTE], [ AS_TR_SH([cc_cv_attribute_$1]), [ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $cc_cv_werror" - AC_COMPILE_IFELSE([$3], + AC_COMPILE_IFELSE([AC_LANG_SOURCE([$3])], [eval "AS_TR_SH([cc_cv_attribute_$1])='yes'"], [eval "AS_TR_SH([cc_cv_attribute_$1])='no'"]) CFLAGS="$ac_save_CFLAGS" @@ -257,7 +264,7 @@ AC_DEFUN([CC_FLAG_VISIBILITY], [ cc_cv_flag_visibility='yes', cc_cv_flag_visibility='no') CFLAGS="$cc_flag_visibility_save_CFLAGS"]) - + AS_IF([test "x$cc_cv_flag_visibility" = "xyes"], [AC_DEFINE([SUPPORT_FLAG_VISIBILITY], 1, [Define this if the compiler supports the -fvisibility flag]) @@ -295,11 +302,11 @@ AC_DEFUN([CC_ATTRIBUTE_ALIGNED], [ [ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS $cc_cv_werror" for cc_attribute_align_try in 64 32 16 8 4 2; do - AC_COMPILE_IFELSE([ + AC_COMPILE_IFELSE([AC_LANG_SOURCE([ int main() { static char c __attribute__ ((aligned($cc_attribute_align_try))) = 0; return c; - }], [cc_cv_attribute_aligned=$cc_attribute_align_try; break]) + }])], [cc_cv_attribute_aligned=$cc_attribute_align_try; break]) done CFLAGS="$ac_save_CFLAGS" ]) -- 1.8.3.1

1 0

[alsa-devel] [PATCH for-5.6 0/4] ALSA: ctl: UAPI updates for obsoleted members
by Takashi Sakamoto 23 Dec '19

23 Dec '19

Hi, As a result of applying patchset for Y2038 issue[1], 'snd_ctl_elem_value' structure is changed to lost 'tstamp' member. This change should corresponds to removal of an access flag of 'snd_ctl_elem_info' structure. These changes brings slight lose of backward compatibility, thus it's better to bump protocol version. Additionally, for recent few year I work to obsolete 'dimen' member from 'snd_ctl_elem_info' structure. It's good timing to attempt toward it. This patchset includes these changes and bump the version up to v2.1.0. [1] https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160082.… Takashi Sakamoto (4): ALSA: ctl: remove unused macro for timestamping of elem_value ALSA: pci: echoaudio: remove usage of dimen menber of elem_value structure ALSA: ctl: remove dimen member from elem_info structure ALSA: ctl: bump protocol version up to v2.1.0 include/uapi/sound/asound.h | 10 +++------- sound/core/control.c | 32 -------------------------------- sound/pci/echoaudio/echoaudio.c | 11 ----------- 3 files changed, 3 insertions(+), 50 deletions(-) -- 2.20.1

2 5

[alsa-devel] [PATCH] ASoC: rt5682: Add option to select pulse IRQ in jack detect
by Akshu Agrawal 23 Dec '19

23 Dec '19

Some SoC need to set IRQ type as pulse along with other JD1 options. Signed-off-by: Akshu Agrawal <akshu.agrawal(a)amd.com> --- include/sound/rt5682.h | 1 + sound/soc/codecs/rt5682.c | 3 +++ sound/soc/codecs/rt5682.h | 2 ++ 3 files changed, 6 insertions(+) diff --git a/include/sound/rt5682.h b/include/sound/rt5682.h index bc2c31734df1..64cfa77ec9ee 100644 --- a/include/sound/rt5682.h +++ b/include/sound/rt5682.h @@ -22,6 +22,7 @@ enum rt5682_dmic1_clk_pin { enum rt5682_jd_src { RT5682_JD_NULL, RT5682_JD1, + RT5682_JD2, }; struct rt5682_platform_data { diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index ae6f6121bc1b..5135d7757361 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -1009,6 +1009,9 @@ static int rt5682_set_jack_detect(struct snd_soc_component *component, } switch (rt5682->pdata.jd_src) { + case RT5682_JD2: + regmap_update_bits(rt5682->regmap, RT5682_IRQ_CTRL_2, + RT5682_JD1_PULSE_MASK, RT5682_JD1_PULSE_EN); case RT5682_JD1: snd_soc_component_update_bits(component, RT5682_CBJ_CTRL_2, RT5682_EXT_JD_SRC, RT5682_EXT_JD_SRC_MANUAL); diff --git a/sound/soc/codecs/rt5682.h b/sound/soc/codecs/rt5682.h index 18faaa2a49a0..434b1c9778b2 100644 --- a/sound/soc/codecs/rt5682.h +++ b/sound/soc/codecs/rt5682.h @@ -1091,6 +1091,8 @@ #define RT5682_JD1_POL_MASK (0x1 << 13) #define RT5682_JD1_POL_NOR (0x0 << 13) #define RT5682_JD1_POL_INV (0x1 << 13) +#define RT5682_JD1_PULSE_MASK (0x1 << 10) +#define RT5682_JD1_PULSE_EN (0x1 << 10) /* IRQ Control 3 (0x00b8) */ #define RT5682_IL_IRQ_MASK (0x1 << 7) -- 2.17.1

2 1

[alsa-devel] How to install on debian buster?
by GitHub issues - opened 23 Dec '19

23 Dec '19

alsa-project/alsa-ucm-conf issue #8 was opened from kopax: I use kernel 5.3 on debian buster and I am following thos offical Lenovo tutorial to install the microphone on my x1c7: https://forums.lenovo.com/lnv/attachments/lnv/lx02_en/3199/1/Enabling%20aud… It says: ![image](https://user-images.githubusercontent.com/1866564/71328607-1a5e8180-251a-11ea-8621-1655d7746c60.png) Now the [link](https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm/sof-skl… is 404, what do I need to get now ? Thanks in advance and merry xmas! Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/8 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[alsa-devel] [PATCH v3 0/2] Add the broadmobi BM818
by Angus Ainslie (Purism) 22 Dec '19

22 Dec '19

The broadmobi uses slightly different parameters from the option modems so add the paramters and document them. Changes since v2: Use of_device_get_match_data to get the dai data. Updated subject styles. Changes since v1: Cut back the CC list. Use data from compatible match instead of explicit compatible match. Angus Ainslie (Purism) (2): ASoC: gtm601: add Broadmobi bm818 sound profile dt-bindings: sound: gtm601: add the broadmobi interface .../devicetree/bindings/sound/gtm601.txt | 10 ++++-- sound/soc/codecs/gtm601.c | 31 ++++++++++++++++--- 2 files changed, 35 insertions(+), 6 deletions(-) -- 2.17.1

3 5

[alsa-devel] [sound:for-next 163/166] ./usr/include/sound/hdspm.h:44:2: error: unknown type name '__u32'
by kbuild test robot 22 Dec '19

22 Dec '19

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next head: bfea224d9250e56ed5475bf72190783a7e1d8e43 commit: 4fa406caf950fd46ae06bccf9a4c72171401d203 [163/166] ALSA: hdspm: Drop linux/types.h inclusion in uapi header config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: git checkout 4fa406caf950fd46ae06bccf9a4c72171401d203 # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot <lkp(a)intel.com> All errors (new ones prefixed by >>): In file included from <command-line>:32:0: >> ./usr/include/sound/hdspm.h:44:2: error: unknown type name '__u32' __u32 input_peaks[64]; ^~~~~ ./usr/include/sound/hdspm.h:45:2: error: unknown type name '__u32' __u32 playback_peaks[64]; ^~~~~ ./usr/include/sound/hdspm.h:46:2: error: unknown type name '__u32' __u32 output_peaks[64]; ^~~~~ >> ./usr/include/sound/hdspm.h:48:2: error: unknown type name '__u64' __u64 input_rms[64]; ^~~~~ ./usr/include/sound/hdspm.h:49:2: error: unknown type name '__u64' __u64 playback_rms[64]; ^~~~~ ./usr/include/sound/hdspm.h:50:2: error: unknown type name '__u64' __u64 output_rms[64]; ^~~~~ >> ./usr/include/sound/hdspm.h:52:2: error: unknown type name '__u8' __u8 speed; /* enum {ss, ds, qs} */ ^~~~ ./usr/include/sound/hdspm.h:153:2: error: unknown type name '__u8' __u8 card_type; /* enum hdspm_io_type */ ^~~~ ./usr/include/sound/hdspm.h:156:2: error: unknown type name '__u64' __u64 card_clock; ^~~~~ ./usr/include/sound/hdspm.h:157:2: error: unknown type name '__u32' __u32 master_period; ^~~~~ ./usr/include/sound/hdspm.h:161:4: error: unknown type name '__u8' __u8 sync_wc; /* enum hdspm_sync */ ^~~~ ./usr/include/sound/hdspm.h:162:4: error: unknown type name '__u8' __u8 sync_madi; /* enum hdspm_sync */ ^~~~ ./usr/include/sound/hdspm.h:163:4: error: unknown type name '__u8' __u8 sync_tco; /* enum hdspm_sync */ ^~~~ ./usr/include/sound/hdspm.h:164:4: error: unknown type name '__u8' __u8 sync_in; /* enum hdspm_sync */ ^~~~ ./usr/include/sound/hdspm.h:165:4: error: unknown type name '__u8' __u8 madi_input; /* enum hdspm_madi_input */ ^~~~ ./usr/include/sound/hdspm.h:166:4: error: unknown type name '__u8' __u8 channel_format; /* enum hdspm_madi_channel_format */ ^~~~ ./usr/include/sound/hdspm.h:167:4: error: unknown type name '__u8' __u8 frame_format; /* enum hdspm_madi_frame_format */ ^~~~ ./usr/include/sound/hdspm.h:182:2: error: unknown type name '__u8' __u8 card_type; /* enum hdspm_io_type */ ^~~~ --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

1 0