ASoC: samsung: clean up references to outdated Kconfig symbols

A few series of ARM cleanups regarding S5PC100 and S5PV210 were included in v3.17. These series removed these five Kconfig symbols:

    MACH_AQUILA
    MACH_GONI
    MACH_SMDKC100
    MACH_SMDKC110
    MACH_SMDKV210

This series, done on top of next-20150119, removes the remaining references to those five symbols. (The first two patches are actually resends.)

Paul Bolle (4):
ASoC: samsung: Remove goni or aquila with the WM8994
ASoC: samsung: Remove PCM support for WM8580 on SMDK
ASoC: samsung: MACH_SMDKC100 isn't supported anymore
ASoC: samsung: remove outdated Kconfig references

 sound/soc/samsung/Kconfig          |  24 +--
 sound/soc/samsung/Makefile         |   4 -
 sound/soc/samsung/goni_wm8994.c    | 289 -------------------------------------
 sound/soc/samsung/smdk_wm8580pcm.c | 176 ----------------------
 4 files changed, 2 insertions(+), 491 deletions(-)
 delete mode 100644 sound/soc/samsung/goni_wm8994.c
 delete mode 100644 sound/soc/samsung/smdk_wm8580pcm.c

1.9.3

If you are posting a patch series please ensure that all the patches in the series are threaded in reply to the cover letter (or first patch if there isn't one) so that mail clients can see to display them as a series.

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Patches 2/4, 3/4, and 4/4 didn't apply. Locally I carry them in a tree that constantly rebases on top of linux-next. So locally I carry these patches on top of next-20150204.

What tree would you like me to rebase this onto?

Paul Bolle

What's posted doesn't apply against -next.

As ever submit against the tree listed in MAINTAINERS

git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

TL;DR: what exactly should I resend and when?

That's because of trivial conflicts with commit a59aa180ea56 ("ASoC:
samsung: Replace depends on REGMAP_I2C with depends on I2C"). That commit landed in next-20150127 (ie, eight days after I sent this short series). I guess I resolved these conflicts in the local version of these patches and promptly forgot about them, as they were so trivial.

Which is not entirely obvious, since this series only touches files below sound/soc/samsung/. That directory is mentioned in MAINTAINERS under "ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" and under "SAMSUNG AUDIO (ASoC) DRIVERS". (Why does that directory need two entries?) Neither entry mention a repository.

Anyhow, this entire series will probably now apply to your for-next branch. That's because your for-next branch doesn't contain commit a59aa180ea56 ("ASoC: samsung: Replace depends on REGMAP_I2C with depends on I2C"), which I mentioned above, or commit 6cf2cf315075 ("ASoC:
samsung: Remove goni or aquila with the WM8994"), which is 1/4 of this series, anymore.

See, it turns out there are two sound.git#for-next branches in linux-next. One is done by Takashi, the other by you. Yours is called sound-asoc in Next/Trees, the other sound. sound-asoc contained the two commits I just mentioned in next-20150209. It has dropped both, it seems, by next-20150210, but by then they were already included in Takashi's sound. So these two commits are now in linux-next through that branch. Figuring this all out required quite a bit of head-scratching.

And now I wonder what I should resend: the three patches 2/4, 3/4, and 4/4 with the trivial conflicts resolved or the entire series? And when do you prefer I resend?

Thanks,

Paul Bolle

This is disappointing; you're someone who's been contributing for quite some time now, I'd really expect you to be faimilar with the process of submitting patches and able to identify answers to your questions.

For something like this I'm just not even going to look at what's required to fix up by hand, sorry.

Of course neither of those entries list me either yet you managed to figure out that you should send the patch to me. The same process that helps you identify that things should be submitted to the subsystem maintainers should allow you to identify where they're likely to try to apply changes. Or simply looking at how other similar patches get merged.

Again this is something I'd really expect you to be familiar with. As ever if there are changes you would like to see integrated into the kernel then please submit them using the normal patch submission process.