On Fri, Jul 12, 2019 at 06:04:39PM +0800, Cheng-Yi Chiang wrote:
> Add an op in hdmi_codec_ops so codec driver can register callback
> function to handle plug event.
>
> Driver in DRM can use this callback function to report connector status.
>
> Signed-off-by: Cheng-Yi Chiang <cychiang@xxxxxxxxxxxx>
> ---
> include/sound/hdmi-codec.h | 16 +++++++++++++
> sound/soc/codecs/hdmi-codec.c | 45 +++++++++++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
> index 7fea496f1f34..9a8661680256 100644
> --- a/include/sound/hdmi-codec.h
> +++ b/include/sound/hdmi-codec.h
> @@ -47,6 +47,9 @@ struct hdmi_codec_params {
> int channels;
> };
>
> +typedef void (*hdmi_codec_plugged_cb)(struct device *dev,
> + bool plugged);
> +
I'd like to pose a question for people to think about.
Firstly, typedefs are generally shunned in the kernel. However, for
these cases it seems to make sense.
However, should the "pointer"-ness be part of the typedef or not? To
see what I mean, consider:
typedef void (*hdmi_foo)(void);
int register_foo(hdmi_foo foo);
vs
typedef void hdmi_foo(void);
int register_foo(hdmi_foo *foo);
which is more in keeping with how we code non-typedef'd code - it's
obvious that foo is a pointer while reading the code.
It seems to me that the latter better matches what is in the kernel's
coding style, which states:
In general, a pointer, or a struct that has elements that can
reasonably be directly accessed should **never** be a typedef.
or maybe Documentation/process/coding-style.rst needs updating?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
