forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 140
Merge/sound upstream 20220609 #3691
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
plbossart
merged 234 commits into
thesofproject:topic/sof-dev
from
plbossart:merge/sound-upstream-20220609
Jun 10, 2022
Merged
Merge/sound upstream 20220609 #3691
plbossart
merged 234 commits into
thesofproject:topic/sof-dev
from
plbossart:merge/sound-upstream-20220609
Jun 10, 2022
Conversation
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
Cleanup path for sof_prepare_widgets_in_path() should check if unprepare callback exists before calling it, instead it checks if it does not exist. Fix the check. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220602135757.3335351-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The SAI module on i.MX8MN is almost same as i.MX8MP, So reuse same soc data as i.MX8MP. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1653966123-28217-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
This code is supposed to propagate errors from simple_write_to_buffer() or return -EFAULT if "size != count". However "size" needs to be signed for the code to work correctly and the case where "size == 0" is not handled correctly. Fixes: 066c676 ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Fixes: 2f0b1b0 ("ASoC: SOF: debug: Add support for IPC message injection") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/Yph+Cd+JrfOH0i7z@kili Signed-off-by: Mark Brown <broonie@kernel.org>
This if statement is reversed. In fact, the condition can just be deleted because writing zero bytes is a no-op. Fixes: 066c676 ("ASoC: SOF: ipc-msg-injector: Add support for IPC4 messages") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/Yph+T3PpGCdPsEDj@kili Signed-off-by: Mark Brown <broonie@kernel.org>
If the audio CODEC is playing sound when the system is suspended, it can be left in a state which throws the following error: wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16 Once this error has occurred, the audio will not work again until rebooted. Fix this by configuring SET_SYSTEM_SLEEP_PM_OPS. Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220526182129.538472-1-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the put() method for the deemphasis control returns 0 when a new value is written to the control even if the value changed, meaning events are not generated. Fix this, skip the work of updating the value when it is unchanged and then return 1 after having done so. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220603123937.4013603-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Currently wm_adsp_fw_put() returns 0 rather than 1 when updating the value of the control, meaning that no event is generated to userspace. Fix this by setting the default return value to 1, the code already exits early with a return value of 0 if the value is unchanged. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220603115003.3865834-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
After finishing the playback or recording, the machine driver might call snd_soc_dai_set_pll(codec, pll_id, 0, 0, 0) to stop the internal PLL, but with the codec driver nau8822, it will print error as below: nau8822 0-001a: Unsupported input clock 0 fsl-asoc-card sound-nau8822: failed to stop FLL: -22 Refer to the function wm8962_set_fll() in the codec driver wm8962, if the freq_out is zero, turn off the internal PLL and return 0. Cc: David Lin <ctlin0@nuvoton.com> Cc: John Hsu <kchsu0@nuvoton.com> Cc: Seven Li <wtli@nuvoton.com> Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://lore.kernel.org/r/20220530040151.95221-3-hui.wang@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds YAML schema for DT bindings of Output Processing Engine (OPE) module. It consists of Parametric Equalizer (PEQ) and Multi Band Dynamic Range Compressor (MBDRC) sub blocks and binding doc for these blocks are added as well. The OPE will be registered as an ASoC component and can be plugged into an audio path as per need via ALSA mixer controls. The DT bindings are applicable on Tegra210 and later SoCs where OPE module is present. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1654238172-16293-2-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
The Output Processing Engine (OPE) is one of the AHUB client. It has PEQ (Parametric Equalizer) and MBDRC (Multi Band Dynamic Range Compressor) sub blocks for data processing. The PEQ block gets samples from the MBDRC block. This patch registers OPE driver with ASoC framework. The component driver exposes DAPM widgets, routes and kcontrols for the device. The DAI driver exposes OPE interfaces, which can be used to connect different components in the ASoC layer. Makefile and Kconfig support is added to allow build the driver. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1654238172-16293-3-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add AHUB routes for OPE module. The OPE module can be plugged into audio path as per the need. The routing controls can be used to setup the audio path with OPE similar to the already existing routes. The support is added on Tegra210 and later Tegra SoCs where OPE module is present. Signed-off-by: Sameer Pujar <spujar@nvidia.com> Link: https://lore.kernel.org/r/1654238172-16293-4-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org>
Allow for retrieving string naming a direction of a stream without the need of substream pointer. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Add generic ASoC equivalent of ALSA HD-Audio codec. This codec is designed to follow HDA_DEV_LEGACY convention. Driver wrapps existing hda_codec.c handlers to prevent code duplication within the newly added code. Number of DAIs created is dependent on capabilities exposed by the codec itself. Because of this, single solution can be applied to support every single HD-Audio codec type. At the same time, through the ASoC topology, platform drivers may limit the number of endpoints available to the userspace as codec driver exposes BE DAIs only. Both hda_codec_probe() and hda_codec_remove() declare their expectations on device's usage_count and suspended-status. This is to catch any unexpected behavior as PM-related code for HD-Audio has been changing quite a bit throughout the years. In order for codec DAI list to reflect its actual PCM capabilities, PCMs need to be built and that can only happen once codec device is constructed. To do that, a valid component->card->snd_card pointer is needed. Said pointer will be provided by the framework once all card components are accounted for and their probing can begin. Usage of "binder" BE DAI solves the problem - codec can be listed as one of HD-Audio card components without declaring any actual BE DAIs statically. Relation with hdac_hda: Addition of parallel solution is motivated by behavioral differences between hdac_hda.c and its legacy equivalent found in sound/pci/hda e.g.: lack of dynamic, based on codec capabilities, resource allocation and high cost of removing such differences on actively used targets. Major goal of codec driver presented here is to follow HD-Audio legacy behavior in 1:1 fashion by becoming a wrapper. Doing so increases code coverage of the legacy code and reduces the maintenance cost for both solutions. Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Connect AVS driver with ASoC HDAudio codec with help of this machine board. Similarly to its platform and codec components, DAI links and routes are being created dynamically so single board can be used across all HDAudio codec types. Card makes use of "binder" BE DAI Link so HDAudio codec driver can be listed as one of its components. This allows for BE DAIs to be created dynamically, based on HDAudio codec capabilities. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Support AVS-DMIC configuration by implementing board connecting AVS platform component with DMIC codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-5-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Allow for testing audio streaming over I2S interface through SSP loopback. No actual codec is needed here as board is intended for SSP loopback scenarios only. One playback and one capture endpoint is exposed per SSP port. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-rt274 configuration add machine board connecting AVS platform component driver with rt274 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-rt286 configuration add machine board connecting AVS platform component driver with rt286 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-rt298 configuration add machine board connecting AVS platform component driver with rt298 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-rt5682 configuration add machine board connecting AVS platform component driver with rt5682 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-10-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-nau8825 configuration add machine board connecting AVS platform component driver with nau8825 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-11-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-ssm4567 configuration add machine board connecting AVS platform component driver with ssm4567 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-12-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-max98357a configuration add machine board connecting AVS platform component driver with max98357a codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-13-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-max98373 configuration add machine board connecting AVS platform component driver with max98373 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-14-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
To support AVS-da7219 configuration add machine board connecting AVS platform component driver with da7219 codec one. Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20220511162403.3987658-15-cezary.rojewski@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
The original set_fmt callback always passes clock provider/consumer with respect to the CODEC. This made sense when the framework was directly broken down into platforms and CODECs. Now everything is componentised it simplifies things if each side of the link is just told if it is provider or consumer of the clocks. To start this migration add a new callback that can be used to receive a direct specification of clocking. As there are more CODEC drivers than platform drivers, we make the new flags identical to the old CODEC flags meaning CODEC drivers will not require an update. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220519154318.2153729-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
As part of updating the core to directly tell drivers if they are clock provider or consumer update this CPU side driver to use the new direct callback. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220519154318.2153729-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
As part of updating the core to directly tell drivers if they are clock provider or consumer update these CPU side drivers to use the new direct callback. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220519154318.2153729-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
As part of updating the core to directly tell drivers if they are clock provider or consumer update these CPU side drivers to use the new direct callback. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220519154318.2153729-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
As part of updating the core to directly tell drivers if they are clock provider or consumer update these CPU side drivers to use the new direct callback. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220519154318.2153729-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: While testing fixes for SoundWire race conditions initially reported in [1], I found additional issues in codec drivers. When the order in which drivers are probed is changed, multiple errors are reported, from unbalanced pm_runtime_enable() calls to invalid mutex lock magic numbers, workqueues not initialized and missing resume sequences. In 'nominal' usages, there is no change of functionality, this is just a first step to test random device/driver bind/unbind sequences. Important note: these changes only touch Intel-based platforms, I don't have any background and ability to test on Qualcomm-based devices. [1] https://lore.kernel.org/alsa-devel/d0559e97-c4a0-b817-428c-d3e305390270@linux.intel.com/ Pierre-Louis Bossart (7): ASoC: Realtek/Maxim SoundWire codecs: disable pm_runtime on remove ASoC: rt711-sdca-sdw: fix calibrate mutex initialization ASoC: Intel: sof_sdw: handle errors on card registration ASoC: rt711: fix calibrate mutex initialization ASoC: rt7*-sdw: harden jack_detect_handler ASoC: codecs: rt700/rt711/rt711-sdca: initialize workqueues in probe ASoC: codecs: rt700/rt711/rt711-sdca: resume bus/codec in .set_jack_detect sound/soc/codecs/max98373-sdw.c | 12 +++++++- sound/soc/codecs/rt1308-sdw.c | 11 +++++++ sound/soc/codecs/rt1316-sdw.c | 11 +++++++ sound/soc/codecs/rt5682-sdw.c | 5 ++- sound/soc/codecs/rt700-sdw.c | 6 +++- sound/soc/codecs/rt700.c | 30 +++++++++++------- sound/soc/codecs/rt711-sdca-sdw.c | 9 +++++- sound/soc/codecs/rt711-sdca.c | 40 ++++++++++++------------ sound/soc/codecs/rt711-sdw.c | 9 +++++- sound/soc/codecs/rt711.c | 40 ++++++++++++------------ sound/soc/codecs/rt715-sdca-sdw.c | 12 ++++++++ sound/soc/codecs/rt715-sdw.c | 12 ++++++++ sound/soc/intel/boards/sof_sdw.c | 51 ++++++++++++++++++------------- 13 files changed, 169 insertions(+), 79 deletions(-) -- 2.34.1
Renesas is the only user of ak4613 on upstream for now, and commit f28dbaa ("ASoC: ak4613: add TDM256 support") added TDM256 support. Renesas tested part of it, because of board connection. It was assuming ak4613 is probed via Audio-Graph-Card, but it might be probed via Simple-Audio-Card either. It will indicates WARNING in such case. This patch fixup it. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/87h74v29f7.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Enables the audio mute LEDs and limits the mic boost to avoid picking up noise. Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Tim Crawford <tcrawford@system76.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220608140111.23170-1-tcrawford@system76.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
On i.MX8MM, the MCTL_MCLK_EN bit it is not only the gate for MCLK output to PAD, but also the gate bit between root clock and SAI module, So it is need to be enabled for master mode, otherwise there is no bclk generated. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1652963808-14515-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
The hda_dsp_core_power_up() needs to be exposed so that it can be used in hda-loader.c to correct the boot flow. The first step must not unstall the core, it should only power up the core(s). Add sanity check for the core_mask while exposing it to be safe. Complements: 2a68ff8 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220609085949.29062-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
…followed The hda_dsp_enable_core() is powering up _and_ unstall the core in one call while the first step of the firmware loading must not unstall the core. The core can be unstalled only after the set cpb_cfp and the configuration of the IPC register for the ROM_CONTROL message. Complements: 2a68ff8 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220609085949.29062-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Update the comment for the cl_dsp_init() to clarify what is done by the function and use the chip->init_core_mask instead of BIT(0) when unstalling/running the init core. Complements: 2a68ff8 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20220609085949.29062-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: Currently the set_fmt callback always passes clock provider/consumer with respect to the CODEC. This made sense when the framework was directly broken down into platforms and CODECs. However, as things are now broken down into components which can be connected as either the CPU or CODEC side of a DAI link it simplifies things if each side of the link is just told if it is provider or consumer of the clocks. Making this change allows us to remove one of the last parts of the ASoC core that needs to know if a driver is a CODEC driver, where it flips the clock format specifier if a CODEC driver is used on the CPU side of a DAI link, as well as just being conceptually more consistent with componentisation. The basic idea of this patch chain is to change the set_fmt callback from specifying if the CODEC is provider/consumer into directly specifying if the component is provider/consumer. To do this we add some new defines, and then to preserve bisectability, the migration is done by adding a new callback, converting over all existing CPU side drivers, converting the core, and then finally reverting back to the old callback. Converting the platform drivers makes sense as the existing defines are from the perspective of the CODEC and there are more CODEC drivers than platform drivers. Obviously a fair amount of this patch chain I was only able to build test, so any testing that can be done would be greatly appreciated.
…lk_prepare_enable Because clk_disable_unprepare/clk_prepare_enable already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com> Link: https://lore.kernel.org/r/20220606033705.291048-1-chi.minghao@zte.com.cn Signed-off-by: Mark Brown <broonie@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
quick upstream merge mainly to check what remains to be sent in this kernel cycle.