On Wed, 12 Dec 2018 16:19:45 +0100, Pierre-Louis Bossart wrote:
diff --git a/include/sound/sof/control.h b/include/sound/sof/control.h
+/* generic channel mapped value data */ +struct sof_ipc_ctrl_value_chan {
- uint32_t channel; /**< channel map - enum sof_ipc_chmap */
- uint32_t value;
Any reason to avoid s32 and u32? If this is supposed to be shared with user-space (or user-space may use this as a reference of data struct), we should consider placing in uapi directory, too.
it's intentional
The includes shared with userspace are in include/uapi/sound/sof.
All the files in include/sound/sof, and this one in particular, are more for host-dsp IPC.
In those two cases, uapi and IPC files, we don't use s32 and u32. we could move this directory under include/uapi/sound/sof-ipc if you prefer?
I don't mind so much but just wondered since it looks as if a part of ABI definition. In anyway, u32/s32 are nicer for kernel codes in general. When I read int32_t or such lengthy form, automatically my alarm chimes as if an alien visiting. But it's also no big deal to keep such types.
BTW, if a file is moved to uapi as a part of ABI, the types should be __u32, not u32.
+void snd_sof_ipc_free(struct snd_sof_dev *sdev) +{
- cancel_work_sync(&sdev->ipc->tx_kwork);
- cancel_work_sync(&sdev->ipc->rx_kwork);
+} +EXPORT_SYMBOL(snd_sof_ipc_free);
Not specific to this function but a general question: why not EXPORT_SYMBOL_GPL() in general in the whole SOF codes?
We use a dual license (copied below)
// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) // // This file is provided under a dual BSD/GPLv2 license. When using or // redistributing this file, you may do so under either license.
Ah, that can of worms... I don't know whether it makes so much sense to keep such a dual license, but I know it's a hairy problem enough for keeping my fingers away.
thanks,
Takashi