summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-03-26Merge tag 'printk-for-6.9-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk fix from Petr Mladek: - Prevent scheduling in an atomic context when printk() takes over the console flushing duty * tag 'printk-for-6.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: printk: Update @console_may_schedule in console_trylock_spinning()
2024-03-26Merge tag 'pwm/for-6.9-rc2-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fix from Uwe Kleine-König: "This contains a single fix for a regression introduced in v5.18-rc1 which made the img pwm driver fail to bind" * tag 'pwm/for-6.9-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: img: fix pwm clock lookup
2024-03-26ASoC: Intel: sof_sdw: Add support for cs42l43 optional speaker outputCharles Keepax
Add support for the optional speaker output on the cs42l43, this uses the new SOF_CODEC_SPKR quirk to conditional include the speaker DAI link. It is worth noting that currently no systems are included that utilise this feature, but the feature is added as several systems are on the horizon. As part of this SOF_SDW_MAX_DAI_NUM must be increased, it is currently 3 but cs42l43 will now have 4 DAI links. This value is increased to 8 to give some head room for future devices. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-35-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Add quirk for optional codec speakersCharles Keepax
Some codecs have speaker drivers that may or may not be used in a given system. Add a quirk (SOF_CODEC_SPKR) that defines if a system uses the codec speaker, this is kept generic such that any codec with such a speaker DAI can reuse the quirk. For implementation of this, add a quirk field into the sof_sdw_dai_info structure. This field is not used to specify if a system uses a particular quirk, that is still done through the sof_sdw_quirk variable, this field is used to flag a DAI as conditional on a certain quirk. This means the DAI will only be included in the card if sof_sdw_quirk and the DAI quirk field have a matching set bit. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-34-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Remove redundant initialisationsCharles Keepax
Unspecified fields are by default initialised to zero, remove redundant init pointer initialisations. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-33-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Don't pass acpi_link_adr to init functionsCharles Keepax
There is no need to pass the snd_soc_acpi_link_adr structure to the init functions, it conveys no specific information about the codec. Remove this parameter from the callbacks Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-32-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: change cs35l56 name_prefixBard Liao
To use sequential amp numbers. I,e, AMP1, AMP2, AMP3, AMP4 Reviewed-by: Chao Song <chao.song@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-31-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: change rt715-sdca dai nameBard Liao
As rt715-sdca dai name has been changed in codec driver, we should change it in machine driver, too. Changing the dai name in codec_info_list[] also help sof_sdw_rtd_init() to run .rtd_init() from the same codec. Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-30-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: rt715-sdca: rename dai name with rt715-sdca prefixBard Liao
The dai name are the same as rt715 codec. Rename them with rt715-sdca prefix allow machine driver to distinguish rt715 and rt715-sdca from dai name. Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-29-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw_rt722_sdca: use rt_dmic_rtd_initBard Liao
rt_dmic_rtd_init() can be used for rt722 dmic, too. Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-28-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw_rt722_sdca: set rtd_init in codec_info_list[]Bard Liao
Add rt722 into rt_sdca_jack_rtd_init() supported list, and set rtd_init callback directly in codec_info_list[]. No need to use a init callback to set the rtd_init callback. Besides, sof_sdw_rt_sdca_jack_init() doesn't set .rtd_init anymore. Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-27-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: remove unused rt dmic rtd_initBard Liao
Some Realtek SDW DMIC codecs use the generic rt_dmic_rtd_init callback now. Remove unused rtd_init callbacks. Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-26-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: use generic rtd_init function for Realtek SDW DMICsBard Liao
The only thing that the rt_xxx_rtd_init() functions do is to set card->components. And we can set card->components with name_prefix as rt712_sdca_dmic_rtd_init() does. And sof_sdw_rtd_init() will always select the first dai with the given dai->name from codec_info_list[]. Unfortunately, we have different codecs with the same dai name. For example, dai name of rt715 and rt715-sdca are both "rt715-aif2". Using a generic rtd_init allow sof_sdw_rtd_init() run the rtd_init() callback from a similar codec dai. Fixes: 8266c73126b7 ("ASoC: Intel: sof_sdw: add common sdw dai link init") Reviewed-by: Chao Song <chao.song@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-25-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Factor out SoundWire DAI creationCharles Keepax
Factor out the creation of the SoundWire DAI links into a helper function. No functional change. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-24-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move generation of DAI links to new parsingCharles Keepax
The only part left using the old parsing code is now the generation of the actual DAI links. Move this generation over to being based on the new parsing, which allows the removal of the last of the old parsing code. The new DAI link generation is a simple matter of creating a new DAI link for each sof_sdw_dailink struct, and adding a cpu, a codec, and a mapping for each sof_sdw_endpoint contained in that sof_sdw_dailink. Note that the CPUs can be inferred as the endpoint list is iterated, because the endpoints were added into the list sorted by link. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-23-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move append_dai_type to new parsingCharles Keepax
append_dai_type should be set to true in any situation that would result in multiple DAI links existing on a single SoundWire bus, because the legacy naming used only the bus number to make things unique. The current code handles this by looking for codecs with multiple dai_info structs and looking for buses that include multiple types of device on them. The first of these assumes that all DAIs on a given device would be in use. The second, with dissimilar aggregation now being supported, isn't really an accurate check either since those devices could be aggregated into a single DAI link. Move the handling for this flag over to the new parsing code and simplify things a little by looking directly for SoundWire links that will contain multiple DAI links to set the flag. These changes should not cause any change in behaviour for any currently supported systems. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-22-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move ignore_pch_dmic to new parsingCharles Keepax
Trivial move of the handling of ignore_pch_dmic over to the new parsing code. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-21-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move counting and codec_conf to new parsingCharles Keepax
Use the output of the new snd_soc_acpi struct parsing for the purposes of counting the number of SoundWire DAI links and physical devices attached to the SoundWire. These counts are already returned by the parser so those can just be used directly. But the population of the codec_conf structures, is moved from the old parsing code over to the new. As the two parsers currently co-exist it is better to not have them both attempt to modify the same structures. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-20-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof-sdw: Add new code for parsing the snd_soc_acpi structsCharles Keepax
The current machine driver code has a lot of loops parsing through the ACPI structs (snd_soc_acpi_link_adr, snd_soc_acpi_adr_device, snd_soc_acpi_endpoint), this makes it hard to understand exactly what information is being extracted and for what purposes. As well as being slightly inefficient, as the same information is looked up multiple times. There are also some issues with the handling of multiple endpoints on a single device, only the first of the snd_soc_acpi_endpoint structures is currently fully processed by the driver. This means doing things like aggregating the second endpoint on a device with another device are not currently possible. Add new parsing code that will count the devices and endpoints, parse them into an intermediate datastructure, and then use that to create the DAI links. This patch does not actually utilise the results of the parsing, items will be moved across in the following patches. This parsing is based around two new structures which are temporarily allocated whilst parsing. Firstly, sof_sdw_endpoint, which represents a specific endpoint for audio on a device and is more or less directly equivalent to snd_soc_acpi_endpoint. Secondly, sof_sdw_dailink which represents a DAI link and contains a linked list of one or more sof_sdw_endpoints. A single trip through the snd_soc_acpi data structures is used to populate these. One important point to note here is the use of the num field in snd_soc_acpi_endpoint to address sof_sdw_dai_info array in the sof_sdw_codec_info struct. This expects a one to one mapping between endpoints on a device and dai infos. It would be fine for a specific system to not specify an endpoint for all of the dai infos available, but two endpoints mapping to the same dai info would make not sense. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-19-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: soc-acpi: Add missing cs42l43 endpointsCharles Keepax
Currently the cs42l43 just specifies a single endpoint, as the current machine driver only looks at the first endpoint specified. Future refactoring will process all endpoints, as such proper specification should be added for all the cs42l43 endpoints. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-18-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Remove no longer supported quirkCharles Keepax
The SOF_SDW_NO_AGGREGATION quirk is mostly for debug and no longer works correctly with the current state of the machine driver. Remove it from the code and add an error message if someone uses it. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-17-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: soc-acpi-intel-arl-match: Add rt711 sdca codec supportBalamurugan C
Adding rt711 sdca codec support for arl boards. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Signed-off-by: Balamurugan C <balamurugan.c@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-16-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Factor out codec name generationCharles Keepax
In preparation for future refactoring pull out a helper specifically for generating the codec name. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-15-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Factor out BlueTooth DAI creationCharles Keepax
Factor out the creation of the BlueTooth DAI links into a helper function. No functional change. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-14-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Factor out HDMI DAI creationCharles Keepax
Factor out the creation of the HDMI DAI links into a helper function. No functional change. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-13-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Factor out DMIC DAI creation.Charles Keepax
Factor out the creation of the DMIC DAI links into a helper function. No functional change. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-12-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Factor out SSP DAI creationCharles Keepax
Factor out the creation of the SSP DAI links into a helper function. No functional change. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Use for_each_set_bitCharles Keepax
Rather than open coding a loop to process each bit use for_each_set_bit. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Only pass dai_link pointer aroundCharles Keepax
Rather than passing around a pointer to the dai_link array and an index into this array, simply pass a pointer to the current dai_link. Also move the DAI link pointer sanity check to the end of the DAI link creation, and change it to a warn on. This check should only be hit if there is a serious bug in the machine driver, so checking it on each iteration is excessive. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move flags to private structCharles Keepax
Move the flags ignore_pch_dmic and append_dai_type into the drivers private structure rather than passing them around between functions. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: Intel: sof_sdw: Move get_codec_dai_by_name() into sof_sdw itselfCharles Keepax
Currently sof_sdw relies on sof_board_helpers to provide get_codec_dai_by_name(), but that is the only function from sof_board_helpers it uses and no other machine driver requires that function. There is no reason for sof_sdw to select SSP_COMMON but more and more functions in sof_board_helpers are gaining dependencies on functions that would require stubs for sof_sdw to build without it. Firstly it was sof_ssp_get_codec_name(), as was fixed in commit c1469c3a8a30 ("ASoC: Intel: ssp-common: Add stub for sof_ssp_get_codec_name"), now it is: ERROR: modpost: "sof_ssp_detect_amp_type" [sound/soc/intel/boards/snd-soc-intel-sof-board-helpers.ko] undefined! ERROR: modpost: "sof_ssp_detect_codec_type" [sound/soc/intel/boards/snd-soc-intel-sof-board-helpers.ko] undefined! Rather than adding more stubs, simply move the affected function to the sof_sdw machine driver itself and no longer select SND_SOC_INTEL_SOF_BOARD_HELPERS at all. This should allow work on SSP_COMMON to progress without affecting sof_sdw. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Set channel map directly from endpointsCharles Keepax
The current code evenly distributes the CODEC DAIs across the CPU DAIs in the DAI link, but this is just an assumption about how the devices are connected to the host. All the information about which CODEC is connected to which CPU DAI is contained in the endpoints datastructures and those structures are already parsed to work out which CODECs to include in the DAI link. Simply fill in the mapping from CPUs -> CODECs as we parse through the endpoints structures, this will ensure that mapping matches the physical layout. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Only pass codec_conf pointer aroundCharles Keepax
Rather than passing around a pointer to the codec_conf array, an index into it and a size, simply pass around a pointer to the current codec_conf. This reduces the amount of state moving around. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Make find_codec_info_dai() return a pointerCharles Keepax
Rather than returning an index simply return a pointer to the located codec info, this simplifies all the callers which only want to access the codec info structure. Also remove the inline specifier the function is fairly large for an inline function, let the compiler decide. And move the function such that it is located with the other find_codec_info_*() functions. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Make find_codec_info_acpi() return a pointerCharles Keepax
Rather than returning an index simply return a pointer to the located codec info, this simplifies all the callers which only want to access the codec info structure. Also remove the inline specifier the function is fairly large for an inline function, let the compiler decide. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: intel: sof_sdw: Make find_codec_info_part() return a pointerCharles Keepax
Rather than returning an index simply return a pointer to the located codec info, this simplifies all the callers which only want to access the codec info structure. Also remove the inline specifier the function is fairly large for an inline function, let the compiler decide. Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://msgid.link/r/20240326160429.13560-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26btrfs: fix race in read_extent_buffer_pages()Tavian Barnes
There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. Fixes: d7172f52e993 ("btrfs: use per-buffer locking for extent_buffer reading") Link: https://lore.kernel.org/linux-btrfs/CAHk-=whNdMaN9ntZ47XRKP6DBes2E5w7fi-0U3H2+PS18p+Pzw@mail.gmail.com/ Link: https://lore.kernel.org/linux-btrfs/f51a6d5d7432455a6a858d51b49ecac183e0bbc9.1706312914.git.wqu@suse.com/ Link: https://lore.kernel.org/linux-btrfs/c7241ea4-fcc6-48d2-98c8-b5ea790d6c89@gmx.com/ CC: stable@vger.kernel.org # 6.5+ Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Tavian Barnes <tavianator@tavianator.com> Reviewed-by: David Sterba <dsterba@suse.com> [ minor update of changelog ] Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: return accurate error code on open failure in open_fs_devices()Anand Jain
When attempting to exclusive open a device which has no exclusive open permission, such as a physical device associated with the flakey dm device, the open operation will fail, resulting in a mount failure. In this particular scenario, we erroneously return -EINVAL instead of the correct error code provided by the bdev_open_by_path() function, which is -EBUSY. Fix this, by returning error code from the bdev_open_by_path() function. With this correction, the mount error message will align with that of ext4 and xfs. Reviewed-by: Boris Burkov <boris@bur.io> Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: zoned: don't skip block groups with 100% zone unusableJohannes Thumshirn
Commit f4a9f219411f ("btrfs: do not delete unused block group if it may be used soon") changed the behaviour of deleting unused block-groups on zoned filesystems. Starting with this commit, we're using btrfs_space_info_used() to calculate the number of used bytes in a space_info. But btrfs_space_info_used() also accounts btrfs_space_info::bytes_zone_unusable as used bytes. So if a block group is 100% zone_unusable it is skipped from the deletion step. In order not to skip fully zone_unusable block-groups, also check if the block-group has bytes left that can be used on a zoned filesystem. Fixes: f4a9f219411f ("btrfs: do not delete unused block group if it may be used soon") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: use btrfs_warn() to log message at btrfs_add_extent_mapping()Filipe Manana
At btrfs_add_extent_mapping(), if we failed to merge the extent map, which is unexpected and theoretically should never happen, we use WARN_ONCE() to log a message which is not great because we don't get information about which filesystem it relates to in case we have multiple btrfs filesystems mounted. So change this to use btrfs_warn() and surround the error check with WARN_ON() so we always get a useful stack trace and the condition is flagged as "unlikely" since it's not expected to ever happen. Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: fix message not properly printing interval when adding extent mapFilipe Manana
At btrfs_add_extent_mapping(), if we are unable to merge the existing extent map, we print a warning message that suggests interval ranges in the form "[X, Y)", where the first element is the inclusive start offset of a range and the second element is the exclusive end offset. However we end up printing the length of the ranges instead of the exclusive end offsets. So fix this by printing the range end offsets. Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: fix warning messages not printing interval at unpin_extent_range()Filipe Manana
At unpin_extent_range() we print warning messages that are supposed to print an interval in the form "[X, Y)", with the first element being an inclusive start offset and the second element being the exclusive end offset of a range. However we end up printing the range's length instead of the range's exclusive end offset, so fix that to avoid having confusing and non-sense messages in case we hit one of these unexpected scenarios. Fixes: 00deaf04df35 ("btrfs: log messages at unpin_extent_range() during unexpected cases") Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: fix extent map leak in unexpected scenario at unpin_extent_cache()Filipe Manana
At unpin_extent_cache() if we happen to find an extent map with an unexpected start offset, we jump to the 'out' label and never release the reference we added to the extent map through the call to lookup_extent_mapping(), therefore resulting in a leak. So fix this by moving the free_extent_map() under the 'out' label. Fixes: c03c89f821e5 ("btrfs: handle errors returned from unpin_extent_cache()") Reviewed-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: validate device maj:min during openAnand Jain
Boris managed to create a device capable of changing its maj:min without altering its device path. Only multi-devices can be scanned. A device that gets scanned and remains in the btrfs kernel cache might end up with an incorrect maj:min. Despite the temp-fsid feature patch did not introduce this bug, it could lead to issues if the above multi-device is converted to a single device with a stale maj:min. Subsequently, attempting to mount the same device with the correct maj:min might mistake it for another device with the same fsid, potentially resulting in wrongly auto-enabling the temp-fsid feature. To address this, this patch validates the device's maj:min at the time of device open and updates it if it has changed since the last scan. CC: stable@vger.kernel.org # 6.7+ Fixes: a5b8a5f9f835 ("btrfs: support cloned-device mount capability") Reported-by: Boris Burkov <boris@bur.io> Co-developed-by: Boris Burkov <boris@bur.io> Reviewed-by: Boris Burkov <boris@bur.io># Signed-off-by: Anand Jain <anand.jain@oracle.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26btrfs: zoned: fix use-after-free in do_zone_finish()Johannes Thumshirn
Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish(). The sequence of events is as follows: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device The reason for this is that we're using a cached pointer to the chunk_map from the block group, but on device replace this cached pointer can contain stale device entries. The staleness comes from the fact, that btrfs_block_group::physical_map is not a pointer to a btrfs_chunk_map but a memory copy of it. Also take the fs_info::dev_replace::rwsem to prevent btrfs_dev_replace_update_device_in_mapping_tree() from changing the device underneath us again. Note: btrfs_dev_replace_update_device_in_mapping_tree() is holding fs_info::mapping_tree_lock, but as this is a spinning read/write lock we cannot take it as the call to blkdev_zone_mgmt() requires a memory allocation which may not sleep. But btrfs_dev_replace_update_device_in_mapping_tree() is always called with the fs_info::dev_replace::rwsem held in write mode. Many thanks to Shinichiro for analyzing the bug. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com> CC: stable@vger.kernel.org # 6.8 Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2024-03-26ASoC: codecs: Add RK3308 internal audio codec driverLuca Ceresoli
Add driver for the internal audio codec of the Rockchip RK3308 SoC. Initially based on the vendor kernel driver [0], with lots of cleanups, fixes, improvements, conversion to DAPM and removal of some features. [0] https://github.com/rockchip-linux/kernel/blob/develop-4.19/sound/soc/codecs/rk3308_codec.c Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://msgid.link/r/20240305-rk3308-audio-codec-v4-4-312acdbe628f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: core: add SOC_DOUBLE_RANGE_TLV() helper macroLuca Ceresoli
No macro currently allows handling a stereo control that has left and right in the same register and whose minimum register value is not zero. Add one that does that. Note that even though the snd_soc_*_volsw_range() look more appropriate given the _range suffix, they are not suitable because they don't honor the two shift values. The snd_soc_*_volsw() look more generic and are suitable for the task. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://msgid.link/r/20240305-rk3308-audio-codec-v4-3-312acdbe628f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26ASoC: dt-bindings: Add Rockchip RK3308 internal audio codecLuca Ceresoli
Add device tree bindings document for the internal audio codec of the Rockchip RK3308 SoC. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://msgid.link/r/20240305-rk3308-audio-codec-v4-2-312acdbe628f@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-03-26Merge branch 'there-are-some-bugfix-for-the-hns3-ethernet-driver'Paolo Abeni
Jijie Shao says: ==================== There are some bugfix for the HNS3 ethernet driver ==================== Link: https://lore.kernel.org/r/20240325124311.1866197-1-shaojijie@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-03-26net: hns3: mark unexcuted loopback test result as UNEXECUTEDJian Shen
Currently, loopback test may be skipped when resetting, but the test result will still show as 'PASS', because the driver doesn't set ETH_TEST_FL_FAILED flag. Fix it by setting the flag and initializating the value to UNEXECUTED. Fixes: 4c8dab1c709c ("net: hns3: reconstruct function hns3_self_test") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>