Message ID | 20210902181217.2958966-1-nathan@kernel.org (mailing list archive) |
---|---|
State | Accepted |
Commit | b3dded7e2f98e2672deb9606514c0e13e3094640 |
Headers | show |
Series | [for-5.15,v3] ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select | expand |
On Thu, Sep 02, 2021 at 11:12:18AM -0700, Nathan Chancellor wrote: > When CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is enabled without > CONFIG_EXPERT, there is a Kconfig warning about unmet dependencies: To repeat what I already said in this thread: the reason this will have got buried last time is that you sent the prior version in reply to an old thread. This new version has also been sent in reply to an old thread which almost had the same effect. Please stop doing that, and also please pay attention to feedback. Please don't send new patches in reply to old patches or serieses, this makes it harder for both people and tools to understand what is going on - it can bury things in mailboxes and make it difficult to keep track of what current patches are, both for the new patches and the old ones.
On Fri, Sep 03, 2021 at 11:27:38AM +0100, Mark Brown wrote: > On Thu, Sep 02, 2021 at 11:12:18AM -0700, Nathan Chancellor wrote: > > When CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is enabled without > > CONFIG_EXPERT, there is a Kconfig warning about unmet dependencies: > > To repeat what I already said in this thread: the reason this will have > got buried last time is that you sent the prior version in reply to an > old thread. This new version has also been sent in reply to an old > thread which almost had the same effect. Please stop doing that, and > also please pay attention to feedback. Sorry, I was not meaning to ignore feedback. I interpreted "this was sent in reply..." as "Pierre-Louis's message was sent in reply..." not "the v2 patch was sent in reply...". > Please don't send new patches in reply to old patches or serieses, this > makes it harder for both people and tools to understand what is going > on - it can bury things in mailboxes and make it difficult to keep track > of what current patches are, both for the new patches and the old ones. For the record, the documentation for sending patches has the "Explicit In-Reply-To headers" section, which frowns on doing this for multi-patch series but never mentions this for single patches. I have never had a maintainer complain about me doing this in the over three years that I have been doing this. It is helpful for me as a developer to see the review history of a patch at times so keeping them altogether is nice but if this is going to be a problem, I'll just get in the habit of providing links to the previous postings on lore.kernel.org in the changelog section. Maybe the documentation could be updated to frown upon adding In-Reply-To headers to new versions of patches period? I can draft up a patch to clarify that. Do you want me to resend v3 without an In-Reply-To header or can you pick it up as is? Cheers, Nathan
On Thu, 2 Sep 2021 11:12:18 -0700, Nathan Chancellor wrote: > When CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH is enabled without > CONFIG_EXPERT, there is a Kconfig warning about unmet dependencies: > > WARNING: unmet direct dependencies detected for SND_SOC_SDW_MOCKUP > Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && > EXPERT [=n] && SOUNDWIRE [=y] > Selected by [y]: > - SND_SOC_INTEL_SOUNDWIRE_SOF_MACH [=y] && ... > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: Intel: boards: Fix CONFIG_SND_SOC_SDW_MOCKUP select commit: b3dded7e2f98e2672deb9606514c0e13e3094640 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
On Fri, Sep 03, 2021 at 08:14:30AM -0700, Nathan Chancellor wrote: > For the record, the documentation for sending patches has the "Explicit > In-Reply-To headers" section, which frowns on doing this for multi-patch > series but never mentions this for single patches. I have never had a > maintainer complain about me doing this in the over three years that I I don't *mind*, there's just a chance I won't notice a patch that appears in the middle of a thread which submitters tend to mind - the issue is that I'm blissfully unaware. It was more that you were doing the exact same thing again in response to it being explicitly identified as an issue. > changelog section. Maybe the documentation could be updated to frown > upon adding In-Reply-To headers to new versions of patches period? I can > draft up a patch to clarify that. Not everyone has a process which causes issues here (and even for me I'd only notice if the old thread was still in my inbox), but I certainly wouldn't be against it. Note that if you're trying to make everything super rules based you also need to cover the case of people trying to incrementally fix a series by sending new versions of patches in the middle of it which is an even worse mess.
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index 046955bf717c..61b71d6c44cf 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -602,7 +602,7 @@ config SND_SOC_INTEL_SOUNDWIRE_SOF_MACH select SND_SOC_DMIC select SND_SOC_INTEL_HDA_DSP_COMMON select SND_SOC_INTEL_SOF_MAXIM_COMMON - select SND_SOC_SDW_MOCKUP + imply SND_SOC_SDW_MOCKUP help Add support for Intel SoundWire-based platforms connected to MAX98373, RT700, RT711, RT1308 and RT715