From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> To: Greg KH <gregkh@linuxfoundation.org> Cc: alsa-devel@alsa-project.org, tiwai@suse.de, linux-kernel@vger.kernel.org, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, vkoul@kernel.org, broonie@kernel.org, srinivas.kandagatla@linaro.org, jank@cadence.com, slawomir.blauciak@intel.com, Sanyog Kale <sanyog.r.kale@intel.com>, Bard liao <yung-chuan.liao@linux.intel.com>, Rander Wang <rander.wang@linux.intel.com> Subject: Re: [alsa-devel] [PATCH v4 08/15] soundwire: add initial definitions for sdw_master_device Date: Mon, 16 Dec 2019 11:07:59 -0600 [thread overview] Message-ID: <c8dfb12c-2394-3dfe-571d-dcc5fadb8dc2@linux.intel.com> (raw) In-Reply-To: <20191216162517.GA2258618@kroah.com> >>>> diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile >>>> index 76a5c52b12b4..5bad8422887e 100644 >>>> --- a/drivers/soundwire/Makefile >>>> +++ b/drivers/soundwire/Makefile >>>> @@ -7,9 +7,11 @@ ccflags-y += -DDEBUG >>>> #Bus Objs >>>> soundwire-bus-objs := bus_type.o bus.o master.o slave.o mipi_disco.o >>>> stream.o >>>> obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o >>>> +ccflags-$(CONFIG_SOUNDWIRE) += -DDEFAULT_SYMBOL_NAMESPACE=SDW_CORE >>>> >>>> soundwire-generic-allocation-objs := generic_bandwidth_allocation.o >>>> obj-$(CONFIG_SOUNDWIRE_GENERIC_ALLOCATION) += >>>> soundwire-generic-allocation.o >>>> +ccflags-$(CONFIG_SOUNDWIRE_GENERIC_ALLOCATION) += >>>> -DDEFAULT_SYMBOL_NAMESPACE=SDW_CORE >>> >>> Don't use ccflags, just use the correct MODULE_EXPORT_NS() tag instead. >> >> The documentation [1] states >> >> " >> Defining namespaces for all symbols of a subsystem can be very verbose and >> may become hard to maintain. Therefore a default define >> (DEFAULT_SYMBOL_NAMESPACE) is been provided, that, if set, will become the >> default for all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() macro expansions >> that do not specify a namespace. >> " >> >> If the ccflags option is not supported or no longer desired, it'd be worth >> updating the documentation for dummies like me. I took the wording as a hint >> to avoid using MODULE_EXPORT_NS. > > It's supported, and works just fine. It's just that you really don't > have a ton of exports, right? What's wrong with manually marking them? I don't see a MODULE_EXPORT_NS so we'd have to change every single EXPORT_SYMBOL to EXPORT_SYMBOL_NS. If we are talking about adding the namespaces just about the top-level functions used by Intel, yes we have less than 10 and since they were renamed it's no big deal. But if we want to use this namespace for lower-level components of the SoundWire code, we have 17 exports in cadence_master.c and more than 27 for the core parts. With the Makefile changes shared last week you'd have 3 changes, I find it more manageable but it's true that the information would be split with the IMPORT_NS in the code and the namespace definition in the Makefile. >>> And "SDW_CORE" is odd, "SOUNDWIRE" instead? >> >> 'sdw' is the prefix used everywhere for SoundWire symbols. > > Ok, I guess that ship has sailed :( we can still use SOUNDWIRE for the namespaces, that'd be fine. you're right to call us on acronyms, it's a bad habit.
WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> To: Greg KH <gregkh@linuxfoundation.org> Cc: alsa-devel@alsa-project.org, tiwai@suse.de, linux-kernel@vger.kernel.org, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, vkoul@kernel.org, broonie@kernel.org, srinivas.kandagatla@linaro.org, jank@cadence.com, slawomir.blauciak@intel.com, Sanyog Kale <sanyog.r.kale@intel.com>, Bard liao <yung-chuan.liao@linux.intel.com>, Rander Wang <rander.wang@linux.intel.com> Subject: Re: [alsa-devel] [PATCH v4 08/15] soundwire: add initial definitions for sdw_master_device Date: Mon, 16 Dec 2019 11:07:59 -0600 [thread overview] Message-ID: <c8dfb12c-2394-3dfe-571d-dcc5fadb8dc2@linux.intel.com> (raw) In-Reply-To: <20191216162517.GA2258618@kroah.com> >>>> diff --git a/drivers/soundwire/Makefile b/drivers/soundwire/Makefile >>>> index 76a5c52b12b4..5bad8422887e 100644 >>>> --- a/drivers/soundwire/Makefile >>>> +++ b/drivers/soundwire/Makefile >>>> @@ -7,9 +7,11 @@ ccflags-y += -DDEBUG >>>> #Bus Objs >>>> soundwire-bus-objs := bus_type.o bus.o master.o slave.o mipi_disco.o >>>> stream.o >>>> obj-$(CONFIG_SOUNDWIRE) += soundwire-bus.o >>>> +ccflags-$(CONFIG_SOUNDWIRE) += -DDEFAULT_SYMBOL_NAMESPACE=SDW_CORE >>>> >>>> soundwire-generic-allocation-objs := generic_bandwidth_allocation.o >>>> obj-$(CONFIG_SOUNDWIRE_GENERIC_ALLOCATION) += >>>> soundwire-generic-allocation.o >>>> +ccflags-$(CONFIG_SOUNDWIRE_GENERIC_ALLOCATION) += >>>> -DDEFAULT_SYMBOL_NAMESPACE=SDW_CORE >>> >>> Don't use ccflags, just use the correct MODULE_EXPORT_NS() tag instead. >> >> The documentation [1] states >> >> " >> Defining namespaces for all symbols of a subsystem can be very verbose and >> may become hard to maintain. Therefore a default define >> (DEFAULT_SYMBOL_NAMESPACE) is been provided, that, if set, will become the >> default for all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() macro expansions >> that do not specify a namespace. >> " >> >> If the ccflags option is not supported or no longer desired, it'd be worth >> updating the documentation for dummies like me. I took the wording as a hint >> to avoid using MODULE_EXPORT_NS. > > It's supported, and works just fine. It's just that you really don't > have a ton of exports, right? What's wrong with manually marking them? I don't see a MODULE_EXPORT_NS so we'd have to change every single EXPORT_SYMBOL to EXPORT_SYMBOL_NS. If we are talking about adding the namespaces just about the top-level functions used by Intel, yes we have less than 10 and since they were renamed it's no big deal. But if we want to use this namespace for lower-level components of the SoundWire code, we have 17 exports in cadence_master.c and more than 27 for the core parts. With the Makefile changes shared last week you'd have 3 changes, I find it more manageable but it's true that the information would be split with the IMPORT_NS in the code and the namespace definition in the Makefile. >>> And "SDW_CORE" is odd, "SOUNDWIRE" instead? >> >> 'sdw' is the prefix used everywhere for SoundWire symbols. > > Ok, I guess that ship has sailed :( we can still use SOUNDWIRE for the namespaces, that'd be fine. you're right to call us on acronyms, it's a bad habit. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-12-16 17:08 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-13 5:03 [PATCH v4 00/15] soundwire: intel: implement new ASoC interfaces Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:03 ` [PATCH v4 01/15] soundwire: renames to prepare support for master drivers/devices Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:03 ` [PATCH v4 02/15] soundwire: rename dev_to_sdw_dev macro Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:03 ` [PATCH v4 03/15] soundwire: rename drv_to_sdw_slave_driver macro Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:03 ` [PATCH v4 04/15] soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:03 ` [PATCH v4 05/15] soundwire: intel: rename res field as link_res Pierre-Louis Bossart 2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 06/15] soundwire: add support for sdw_slave_type Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 7:21 ` Greg KH 2019-12-13 7:21 ` [alsa-devel] " Greg KH 2019-12-13 15:05 ` Pierre-Louis Bossart 2019-12-13 15:05 ` Pierre-Louis Bossart 2019-12-13 16:12 ` Greg KH 2019-12-13 16:12 ` Greg KH 2019-12-13 22:14 ` Pierre-Louis Bossart 2019-12-13 22:14 ` Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 07/15] soundwire: slave: move uevent handling to slave Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 7:22 ` Greg KH 2019-12-13 7:22 ` [alsa-devel] " Greg KH 2019-12-13 15:11 ` Pierre-Louis Bossart 2019-12-13 15:11 ` Pierre-Louis Bossart 2019-12-13 16:11 ` Greg KH 2019-12-13 16:11 ` Greg KH 2019-12-13 22:15 ` Pierre-Louis Bossart 2019-12-13 22:15 ` Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 08/15] soundwire: add initial definitions for sdw_master_device Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 7:28 ` Greg KH 2019-12-13 7:28 ` [alsa-devel] " Greg KH 2019-12-13 15:49 ` Pierre-Louis Bossart 2019-12-13 15:49 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 16:10 ` Greg KH 2019-12-13 16:10 ` [alsa-devel] " Greg KH 2019-12-13 22:15 ` Pierre-Louis Bossart 2019-12-13 22:15 ` Pierre-Louis Bossart 2019-12-16 22:34 ` Pierre-Louis Bossart 2019-12-16 22:34 ` Pierre-Louis Bossart 2019-12-13 23:25 ` Pierre-Louis Bossart 2019-12-13 23:25 ` Pierre-Louis Bossart 2019-12-14 8:27 ` Greg KH 2019-12-14 8:27 ` Greg KH 2019-12-16 15:02 ` Pierre-Louis Bossart 2019-12-16 15:02 ` Pierre-Louis Bossart 2019-12-16 16:25 ` Greg KH 2019-12-16 16:25 ` Greg KH 2019-12-16 17:07 ` Pierre-Louis Bossart [this message] 2019-12-16 17:07 ` Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 09/15] soundwire: intel: remove platform devices and provide new interface Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 10/15] soundwire: register master device driver Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 11/15] soundwire: intel: add prepare support in sdw dai driver Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 12/15] soundwire: intel: add trigger " Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 13/15] soundwire: intel: add sdw_stream_setup helper for .startup callback Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 14/15] soundwire: intel: free all resources on hw_free() Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart 2019-12-13 5:04 ` [PATCH v4 15/15] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart 2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c8dfb12c-2394-3dfe-571d-dcc5fadb8dc2@linux.intel.com \ --to=pierre-louis.bossart@linux.intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=jank@cadence.com \ --cc=linux-kernel@vger.kernel.org \ --cc=rander.wang@linux.intel.com \ --cc=ranjani.sridharan@linux.intel.com \ --cc=sanyog.r.kale@intel.com \ --cc=slawomir.blauciak@intel.com \ --cc=srinivas.kandagatla@linaro.org \ --cc=tiwai@suse.de \ --cc=vkoul@kernel.org \ --cc=yung-chuan.liao@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.