Merge/sound upstream 20220517#3655
Merged
plbossart merged 134 commits intothesofproject:topic/sof-devfrom May 18, 2022
Merged
Conversation
Add a comment to make the purpose of the endianness flag on the snd_soc_component structure more clear. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag should have been removed when the driver was ported across from having both a CODEC and CPU side component, to just having a CPU component and using the dummy for the CODEC. The endianness flag is used to indicate that the device is completely ambivalent to the endianness of the data, typically due to the endianness being lost over the hardware link (ie. the link defines bit ordering). It's usage didn't have any effect when the driver had both a CPU and CODEC component, since the union of those equals the CPU side settings, but now causes the driver to falsely report it supports big endian. Correct this by removing the flag. Fixes: f3c6680 ("ASoC: atmel-pdmic: remove codec component") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag should have been removed when the driver was ported across from having both a CODEC and CPU side component, to just having a CPU component and using the dummy for the CODEC. The endianness flag is used to indicate that the device is completely ambivalent to the endianness of the data, typically due to the endianness being lost over the hardware link (ie. the link defines bit ordering). It's usage didn't have any effect when the driver had both a CPU and CODEC component, since the union of those equals the CPU side settings, but now causes the driver to falsely report it supports big endian. Correct this by removing the flag. Fixes: 1dfdbe7 ("ASoC: atmel-classd: remove codec component") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-7-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-8-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-9-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The CODEC already provides the endianness flag on its snd_soc_component_driver structure, specifying it is ambivalent to endian. The core will expand the formats to cover both endian types, as such remove the redundant specification of both endians. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-10-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an HDA DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-11-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a PDM DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-12-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-13-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-14-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-15-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-16-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-17-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-18-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-19-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. As the core will now expand the formats to cover both endian types, remove the redundant manual specification of both. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-20-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-21-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-22-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-23-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-24-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-25-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over an I2S DAI and as such should have endianness applied. A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported. It is worth noting this changes the behaviour of S24_LE to use a word length of 24 rather than 32. This would appear to be a correction since the fact S24_LE is stored as 32 bits should not be presented over the bus. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-26-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. The i2s_rx component receives audio over an I2S DAI and as such should have endianness applied. A fixup is also required to use the width directly rather than relying on the format in hw_params, now both little and big endian would be supported. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-27-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SLIMbus DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-28-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SLIMbus DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-29-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-30-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-31-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Fix the following coccicheck warning: sound/core/seq/seq_ports.c:142:12-14: WARNING opportunity for max() Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Link: https://lore.kernel.org/r/20220517062518.123292-1-guozhengkui@vivo.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
If user space provides smaller buffer than the IPC4 reply then it is possible that we corrupt user space memory since the IPC4 dfs_read function is not using the count directly in copy_to_user() due to the nature of an IPC4 message. Cap the remaining counter to make sure that we are not writing too much to the user space provided buffer. Add a check also to make sure that the buffer is at least the size of the IPC4 header. Fixes: 066c676: "ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20220516092442.17027-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
clk_put() already checks the clk ptr using !clk and IS_ERR() so there is no need to check it again before calling it. Signed-off-by: Yihao Han <hanyihao@vivo.com> Link: https://lore.kernel.org/r/20220517033050.5191-1-hanyihao@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
plbossart
requested review from
RanderWang,
ajitkupandey,
bardliao,
bhiregoudar,
dbaluta,
jack-cy-yu,
kuanhsuncheng,
kv2019i,
lgirdwood,
naveen-manohar,
oder-chiou,
ranj063,
ryans-lee,
shumingfan,
sunilkumardommati,
ujfalusi and
yaochunhung
as code owners
Member
Author
|
Two unexpected errors, outside of the usual UpExtreme timeouts. Probably need to re-run the tests to double-check the results |
Member
Author
|
SOFCI TEST |
Member
Author
|
All tests passed in https://sof-ci.01.org/linuxpr/PR3655/build124/devicetest/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
probably the last upstream merge for the 5.18 cycle.