Re: [PATCH v3 04/14] ASoC: SOF: Add support for IPC IO between DSP and Host

[Takashi Iwai <tiwai@suse.de>]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel