[alsa-devel] [PATCH] ASoC: ics43432: Fix build errors
Fix build errors
Signed-off-by: Ricard Wanderlof ricardw@axis.com ---
Not sure how the incorrect name or the misspelled license string got through my local build, perhaps because I've been developing this for an ARM system? Have now set up a tree to build for x86 as well, where the errors manifest themselves, to avoid this type of stuff happening in the future.
sound/soc/codecs/ics43432.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/ics43432.c b/sound/soc/codecs/ics43432.c index d217fed..465d591 100644 --- a/sound/soc/codecs/ics43432.c +++ b/sound/soc/codecs/ics43432.c @@ -57,7 +57,7 @@ static const struct of_device_id ics43432_ids[] = { { .compatible = "invensense,ics43432", }, { } }; -MODULE_DEVICE_TABLE(of, ics43432_dt_ids); +MODULE_DEVICE_TABLE(of, ics43432_ids); #endif
static struct platform_driver ics43432_driver = { @@ -73,4 +73,4 @@ module_platform_driver(ics43432_driver);
MODULE_DESCRIPTION("ASoC ICS43432 driver"); MODULE_AUTHOR("Ricard Wanderlof ricardw@axis.com"); -MODULE_LICENSE("GPLv2"); +MODULE_LICENSE("GPL v2");
On Fri, Aug 28, 2015 at 12:11:48PM +0200, Ricard Wanderlof wrote:
Fix build errors
I'll apply this since it fixes a build issue but please as I said in reply to your earlier off list query send one patch per issue (as covered in SubmittingPatches) and try to provide useful changelogs describing the issue being fixed.
Not sure how the incorrect name or the misspelled license string got through my local build, perhaps because I've been developing this for an ARM system? Have now set up a tree to build for x86 as well, where the errors manifest themselves, to avoid this type of stuff happening in the future.
You can't be using a modern ARM system there, modern ARM systems are DT based :(
On Fri, 28 Aug 2015, Mark Brown wrote:
On Fri, Aug 28, 2015 at 12:11:48PM +0200, Ricard Wanderlof wrote:
Fix build errors
I'll apply this since it fixes a build issue but please as I said in reply to your earlier off list query send one patch per issue (as covered in SubmittingPatches) and try to provide useful changelogs describing the issue being fixed.
I purposely grouped both the mismatched variable name and license name into a single patch, because both cause build failures when I tested in an x86 build, the latter resulting in:
. . . Building modules, stage 2. MODPOST 2426 modules FATAL: modpost: GPL-incompatible module snd-soc-ics43432.ko uses GPL-only symbol '__platform_driver_register' make[1]: *** [__modpost] Error 1
I should have been more descriptive in the commit message though. I did feel though that given the diff it was fairly obvious what the problems were so I didn't think it needed further explanation and would only clog up the commit log.
Not sure how the incorrect name or the misspelled license string got through my local build, perhaps because I've been developing this for an ARM system? Have now set up a tree to build for x86 as well, where the errors manifest themselves, to avoid this type of stuff happening in the future.
You can't be using a modern ARM system there, modern ARM systems are DT based :(
Well, I am and it is. :) I double checked that CONFIG_OF was set when compiling the file, and also that the relevant lines of codes were in fact compiled. I don't know if there's any other kernel configuration (either a CONFIG_ option or some build option) which can influence the behavior though.
/Ricard
On Mon, Aug 31, 2015 at 09:14:02AM +0200, Ricard Wanderlof wrote:
On Fri, 28 Aug 2015, Mark Brown wrote:
On Fri, Aug 28, 2015 at 12:11:48PM +0200, Ricard Wanderlof wrote:
I'll apply this since it fixes a build issue but please as I said in reply to your earlier off list query send one patch per issue (as covered in SubmittingPatches) and try to provide useful changelogs describing the issue being fixed.
I purposely grouped both the mismatched variable name and license name into a single patch, because both cause build failures when I tested in an x86 build, the latter resulting in:
That isn't important or helpful, they are still separate build failures and should be sent as separate commits.
I should have been more descriptive in the commit message though. I did feel though that given the diff it was fairly obvious what the problems were so I didn't think it needed further explanation and would only clog up the commit log.
If the commit message is too bad I may not look at the patch. Part of the review is making sure that the commit message describes what the changes are doing to help make sure that the commit does what the author thinks it does.
participants (2)
-
Mark Brown -
Ricard Wanderlof