user/sven/linux.git/include/sound, branch v4.9.6

ASoC: hdmi-codec: use unsigned type to structure members with bit-field

2017-01-19T19:18:02Z

commit 9e4d59ada4d602e78eee9fb5f898ce61fdddb446 upstream. This is a fix for Linux 4.10-rc1. In C language specification, a bit-field is interpreted as a signed or unsigned integer type consisting of the specified number of bits. In GCC manual, the range of a signed bit field of N bits is from -(2^N) / 2 to ((2^N) / 2) - 1 https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Bit-Fields Therefore, when defined as 1 bit-field with signed type, variables can represents -1 and 0. The snd-soc-hdmi-codec module includes a structure which has signed type members with bit-fields. Codes of this module assign 0 and 1 to the members. This seems to result in implementation-dependent behaviours. As of v4.10-rc1 merge window, outside of sound subsystem, this structure is referred by below GPU modules. - tda998x - sti-drm - mediatek-drm-hdmi - msm As long as I review their codes relevant to the structure, the structure members are used just for condition statements and printk formats. My proposal of change is a bit intrusive to the printk formats but this may be acceptable. Totally, it's reasonable to use unsigned type for the structure members. This bug is detected by Sparse, static code analyzer with below warnings. ./include/sound/hdmi-codec.h:39:26: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:40:28: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:41:29: error: dubious one-bit signed bitfield ./include/sound/hdmi-codec.h:42:31: error: dubious one-bit signed bitfield Fixes: 09184118a8ab ("ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders") Signed-off-by: Takashi Sakamoto Acked-by: Arnaud Pouliquen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Merge tag 'asoc-v4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next

2016-09-30T16:40:40Z

ASoC: Updates for v4.9 Apart from the cleanups done by Morimoto-san this has very much been a driver focused release with very little generic change: - A big factoring out of the simple-card code to allow it to be shared more with the rcar generic card from Kuninori Morimoto. - Removal of some operations duplicated on the CODEC level, again by Kuninori Morimoto. - Lots more machine support for x86 systems. - New drivers for Nuvoton NAU88C10, Realtek RT5660 and RT5663.

Merge remote-tracking branches 'asoc/topic/sgtl5000', 'asoc/topic/simple', 'asoc/topic/stac9766', 'asoc/topic/sti' and 'asoc/topic/sunxi' into asoc-next

2016-09-29T19:44:41Z

Merge remote-tracking branches 'asoc/topic/rt5659', 'asoc/topic/rt5660', 'asoc/topic/rt5677' and 'asoc/topic/samsung' into asoc-next

2016-09-29T19:44:37Z

Merge remote-tracking branches 'asoc/topic/nau8810', 'asoc/topic/of-bool', 'asoc/topic/omap' and 'asoc/topic/platform-drvdata' into asoc-next

2016-09-29T19:44:31Z

Merge remote-tracking branches 'asoc/topic/da7218', 'asoc/topic/da7219' and 'asoc/topic/dpcm' into asoc-next

2016-09-29T19:44:21Z

Merge remote-tracking branches 'asoc/topic/ac97', 'asoc/topic/ak4104', 'asoc/topic/arizona', 'asoc/topic/atmel' and 'asoc/topic/codec-component' into asoc-next

2016-09-29T19:44:07Z

Merge remote-tracking branch 'asoc/topic/rcar' into asoc-next

2016-09-29T19:44:02Z

ASoC: da7219: Disable AAD if codec is not a wake-up source

2016-09-26T16:39:50Z

Currently if AAD is enabled in the device, during system suspend the feature remains, regardless of whether the codec is a wake-up source or not. This means some additional power is being used which is unnecessary, and can causes issues with some platforms' IRQ handlers where state changes during system suspend aren't captured. This patch updates the driver to disable AAD during suspend, if we're not a wake-up source, and then re-enables this on resume. Signed-off-by: Adam Thomson Signed-off-by: Mark Brown

ALSA: control: cage TLV_DB_RANGE_HEAD in kernel land because it was obsoleted

2016-09-25T20:16:49Z

In commit bf1d1c9b6179 ("ALSA: tlv: add DECLARE_TLV_DB_RANGE()"), the new macro was added so that "dB range information can be specified without having to count the items manually for TLV_DB_RANGE_HEAD()". In short, TLV_DB_RANGE_HEAD macro was obsoleted. In commit 46e860f76804 ("ALSA: rename TLV-related macros so that they're friendly to user applications"), TLV-related macros are exposed for applications in user land to get content of data structured by Type/Length/Value shape. The commit managed to expose TLV-related macros as many as possible, while obsoleted TLV_DB_RANGE_HEAD() was included to the list of exposed macros. This situation brings some confusions to application developers because they might think all exposed macros have their own purpose and useful for applications. For the reason, this commit moves TLV_DB_RANGE_HEAD macro from UAPI header to a header for kernel land, again. The above commit is done within the same development period for kernel 4.9, thus not published yet. This commit might certainly brings no confusions to user land. Reference: commit bf1d1c9b6179 ("ALSA: tlv: add DECLARE_TLV_DB_RANGE()") Reference: commit 46e860f76804 ("ALSA: rename TLV-related macros so that they're friendly to user applications") Signed-off-by: Takashi Sakamoto Signed-off-by: Takashi Iwai