Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp740967ybi; Fri, 12 Jul 2019 03:58:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmt4TdWbJqjTqZooimyWvqY8ibJ6H6OMVJYczttBCkYmzYnU6LQ0ux2Ejn+G8me0IwHPRK X-Received: by 2002:a17:902:2ac7:: with SMTP id j65mr10792370plb.242.1562929125065; Fri, 12 Jul 2019 03:58:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562929125; cv=none; d=google.com; s=arc-20160816; b=ADExNR+KMyvQERUgvc802z3D90Unm7DVWo0EiA+OoFgQlrHCrd0CMG5x7kcEHb9vwe LuL09vMuMnSjHwb8QjsRWP8PMLk4Ud88WRYT7V6mdPTAsq7whOPFe7ZB0NLXLQWIVUQw 3k4mfGVvzdPhbDvCzAtWtW/edieE/wLKp6d/E0vzDU7lN7tM1CjNlmF83pPirYS5PxEz hFWXej0dUGOoWjLnMEpvHe/PeoXBrIalicu4sUSK3g+Tcf/PUPjbg360X0vS2IS9Qf/K J8G2yf6RyXNnk2jhwXUfffXXQW4cAvmjqgAhqCMlwkWJDzIQesTinMVW7CP10T+zwS69 nXeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=u9dynlJ3OM9MALiJSBcSG7FKkftfyq54pHYRnzPQTFA=; b=LxO5dvzWuqoD5if8q+07HlrOvKCBl8WVIWkSMQurWgemDivs3176Suk9mtBSgOJ2q2 xzol73CJgO6dfL9ndjCUIOtt7PTFGKJPqpy+Qc7aKZcwUZ4wac1UBM6Mal9Ytx76d2hF QN9GvjVoBTa5QQgHcwCXQ9BXe0TQGKEZY/0mNwJpV5H5x5jXw3S3w3uWms/OHBU9DCng Ap2nfGQdoWFXsdsR8hfs7arRhiqsNO9ID6XrShcHP7oIySMHqcsxQuitka1Rw23kMT6A IFok7CQNefPNBZtypOR1aun5Jarsm/P+82Tt2QRGcK9GOFEf/6B3Orur8iZAJj5IaAyo 6nXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Eyr0dtWh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v189si7615590pgd.289.2019.07.12.03.58.29; Fri, 12 Jul 2019 03:58:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=Eyr0dtWh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726892AbfGLK5x (ORCPT + 99 others); Fri, 12 Jul 2019 06:57:53 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:50878 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726050AbfGLK5x (ORCPT ); Fri, 12 Jul 2019 06:57:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u9dynlJ3OM9MALiJSBcSG7FKkftfyq54pHYRnzPQTFA=; b=Eyr0dtWhsmlK2Q6BhgmXpUOL/ qymgs31El0emqh8IFE4WI3vF53WCcBAaX6vLcGPJDEh30I33KI7G6wSoN0u+M/D/BCSA1udbJvErH nIDPBlSdgUpnsnRPshqdgvBlwZh+rqeIGCWGpUc+DhpBYN0jaKp9LJpI4PlEv5yRZ/CSfY7Z8HyYq tBBBAz5DaPhve6iZyWd/UAkz7y6uKCCXVnCCXr3uYXQZrhzPLLkpOn95j/IOhrviJVxEXV07j5CsA RFU80czsdSVH3CRpvfIGSrY4m2mqkYq99uWagRqbIE8jqCXlSABqwIIgCGdgiZ7x8M2xRsZ2I9Q0c 8ZwvU8lPQ==; Received: from shell.armlinux.org.uk ([2002:4e20:1eda:1:5054:ff:fe00:4ec]:59462) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1hltFN-0001Mc-4Y; Fri, 12 Jul 2019 11:57:49 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1hltFJ-0005c2-Nx; Fri, 12 Jul 2019 11:57:45 +0100 Date: Fri, 12 Jul 2019 11:57:45 +0100 From: Russell King - ARM Linux admin To: Cheng-Yi Chiang Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, dianders@chromium.org, Heiko Stuebner , linux-rockchip@lists.infradead.org, David Airlie , dri-devel@lists.freedesktop.org, Takashi Iwai , Liam Girdwood , tzungbi@chromium.org, Jaroslav Kysela , Hans Verkuil , Andrzej Hajda , Mark Brown , Laurent Pinchart , Daniel Vetter , dgreid@chromium.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 1/5] ASoC: hdmi-codec: Add an op to set callback function for plug event Message-ID: <20190712105745.xr7jxc626lwoaajx@shell.armlinux.org.uk> References: <20190712100443.221322-1-cychiang@chromium.org> <20190712100443.221322-2-cychiang@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190712100443.221322-2-cychiang@chromium.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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