Received: by 10.223.185.116 with SMTP id b49csp1040580wrg; Fri, 16 Feb 2018 11:18:24 -0800 (PST) X-Google-Smtp-Source: AH8x226XtmBQiKvDbu+HEuAPlpnUvgFUxE+HYW7tzbL7vAVyoDjWM7LPuVtz1PHGLtK7gTYDtLQb X-Received: by 10.101.102.73 with SMTP id z9mr5918977pgv.448.1518808703887; Fri, 16 Feb 2018 11:18:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518808703; cv=none; d=google.com; s=arc-20160816; b=ccWUHHTSGSO0LfvKO8mIv6VDQiKOjgofMqoMlUPpjdvC3RPO+RFox1KfUpy/JDFJi+ UmfuzsJ7Ra0rMtDtmQQH6ManYV7KC2jtiaSK1ckLDSpPDtxf6qhG5GUvyvakUYnpIA2c nsEZUISKl6PWEIsZmv1aCGajJEhvv23cuKze4vAQLrClAQgfrSuOUsBH5ry0fhZvRzYN AKLkRtVnNVb4yIG6Kqtp3S33Zvz3fJBIOUv2zdRNFr9zEasm6JG7t1c978q7A16SRMfz JuLwntixHMLyYwAgtedwFz8ePm6aLK8jazAgHxbJuKVxtuqd3g45X8cUr/tIJN5ZqH9x RILQ== 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:arc-authentication-results; bh=Fki7VrYvV8jVAxN4nlA9OK1fnegfuXS6MeXk80tedTM=; b=YcgEQRF/sugJIKjuetRz40nAHJi04+UQYPcIWeYYAtqyLVpDg2E3nnhSDO4z0x9Jl5 tmsuBnN2RS/YYebBLUVfzvfaHc5xOoGyjhOqGzHLNLhBoGV33jbEC0IvcTyHiyomi/r4 9jYsiCgBEuOUJZkl2Apn3llUHrSVMFjvcLTNg2njWQji0vtnilUpPR5LS/IJ9KhQHwZi ZvvaM3Ap4vbctDmyoAt9OHTyB3WeyYvnucYL98bF+l/SSvbE0DBrmEULZEbdcj6pvSf8 IviE5A6cbv5YKZ/8eL4/8lbLsP3hIOdbw9LydJyVnLgjFRNubfDHMSqOjGddNhKNmdLl T7yw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3-v6si74370plo.99.2018.02.16.11.18.09; Fri, 16 Feb 2018 11:18:23 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030941AbeBPP5M (ORCPT + 99 others); Fri, 16 Feb 2018 10:57:12 -0500 Received: from muru.com ([72.249.23.125]:57236 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030613AbeBPP5L (ORCPT ); Fri, 16 Feb 2018 10:57:11 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id BCE8E8068; Fri, 16 Feb 2018 15:57:46 +0000 (UTC) Date: Fri, 16 Feb 2018 07:57:07 -0800 From: Tony Lindgren To: Mark Brown Cc: Sebastian Reichel , Liam Girdwood , Rob Herring , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 1/4] dt-bindings: sound: add motorola,cpcap-audio-codec Message-ID: <20180216155706.GS6364@atomide.com> References: <20180214220741.28306-1-sebastian.reichel@collabora.co.uk> <20180214220741.28306-2-sebastian.reichel@collabora.co.uk> <20180216113008.GB5886@sirena.org.uk> <20180216132537.lkd4wzfg7uuoyx7k@earth.universe> <20180216134448.GI5886@sirena.org.uk> <20180216141237.rd75sbix7bopi7zu@earth.universe> <20180216151609.GK5886@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180216151609.GK5886@sirena.org.uk> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mark Brown [180216 15:17]: > On Fri, Feb 16, 2018 at 03:12:37PM +0100, Sebastian Reichel wrote: > > On Fri, Feb 16, 2018 at 01:44:48PM +0000, Mark Brown wrote: > > > On Fri, Feb 16, 2018 at 02:25:38PM +0100, Sebastian Reichel wrote: > > > > > While it looks empty in the DT binding file, it's actually not empty > > > > once some standard properties are added to support audio-graph-card. > > > > This tells me you're missing something in the binding defining the > > > DAIs and... > > > Well it is described by the following document: > > > Documentation/devicetree/bindings/sound/audio-graph-card.txt > > You still need to say which DAIs exist on the device and how they are > identified - if there's only one DAI it's obviously easy but if a device > has multiple DAIs then there's some naming to do. > > > > ...that still doesn't require a compatible here. > > > I agree, that it's not required. Also the node is not required. > > Everything could be dumped into the main node. Many things are > > not required, but they make implementations easier and help in > > regards to DT readability and consistency. Having the compatible > > means, that all sub-functions _can_ be handled equally by the > > operating system. Not having the compatible means you _always_ > > need special handling for the audio codec. This basically makes > > the codec node different for the simple purpose of "because it is > > not strictly required". If we have a compatible node, other > > operating systems can still decide to ignore it, right? > > It's not just other operating systems, it's also other versions of > Linux we have to think about here. The most obvious issue with audio is > the clocking where the division between ASoC and clock APIs is not super > obvious and could easily change in the future. Yeah let's stick to describing how the hardware is wired in the dts files. In this case it's really only the routing to the SoC, right? One advantage of using a compatible property for the pmic subdevices though is that it leaves out a dependency between various device drivers things happen automagically. The mfd core driver can be minimal and just implement interrupt handling and regmap. So no need to to parse the child nodes in the pmic mfd driver :) So personally I'd prefer the option that requires least amount of custom code if compatible vs no compatible property is the only issue here. Regards, Tony