Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4822176imj; Wed, 13 Feb 2019 01:31:00 -0800 (PST) X-Google-Smtp-Source: AHgI3IYRlCBdGRMvIslkyGRbhEB/Ho3f8zl9GbbCIvKecHYnLs7CzFW/curu/BLhLRARya/3tgkX X-Received: by 2002:a62:bd17:: with SMTP id a23mr6091301pff.233.1550050260169; Wed, 13 Feb 2019 01:31:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550050260; cv=none; d=google.com; s=arc-20160816; b=iPBzNOAFxjonDiPfzOe+K5aVSkCQuFBT2REiXh90QkFXTwFM1QKIiiqq5fo/uhf5mf rxLl7rOhKiZMDmoD4s+VOd8W5wW+m7+5kuWGcqc14sftFcjkClmg+jbptHwOCGFfBZWt MzpImiZvSdmnFkMfWaKhf1R9xKBuRbnQP/byQRlNC2wChvx97A6YhvyJwnFJuLH9b7xx asFf2DswKtGazGf0Ilh1J1wcC4loj7BcPALK0tZJFKyS9tM+NXIU3qu0tD4BstmJjXeZ MRcXL07fxDityDibhv11qsZPzArjbD9Kfl29zBfJOLYossfFtotmhiXWDaoXEYnVlvAs VJew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PeCBPDtNKEuaDKuiaHAzR3WaJUZOBwZPqqRsoj6cyhI=; b=krpmp7IgU8TJUfWtry1jPyiDVpd3doXuWrEuH6Bc2iQuzpekONf7W6gTFGWeP5KpjH U3gIX1V28OjviWlLz+ZQ4UlIVXiU03Qi5Z6WbA7kQi7XiTEBX0uQuMn5c8eELEV94UIx 9ZUXsfQgG5JvUj/w2BixmEgDFaqRLk82SECTp+3HX+I29KpoOqHJlOjS72XVf7MmDEz6 KREveClJF3EJCNS+tD262AGldEIBy4uWxz5Inn9ZxPh/SwYWPaqZC+V8KOWYx6QLqbem 8skuzrG2J03WHGhTNZJEDXidjDXtJ8p7gju06siw7vpJOARVrbMC7/LZlzVfj4RHI5AG MT3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UPkdxirG; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12si14077934pfd.183.2019.02.13.01.30.44; Wed, 13 Feb 2019 01:31:00 -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; dkim=pass header.i=@linaro.org header.s=google header.b=UPkdxirG; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728677AbfBMFqH (ORCPT + 99 others); Wed, 13 Feb 2019 00:46:07 -0500 Received: from mail-lf1-f67.google.com ([209.85.167.67]:42289 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725562AbfBMFqH (ORCPT ); Wed, 13 Feb 2019 00:46:07 -0500 Received: by mail-lf1-f67.google.com with SMTP id l10so807223lfh.9 for ; Tue, 12 Feb 2019 21:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PeCBPDtNKEuaDKuiaHAzR3WaJUZOBwZPqqRsoj6cyhI=; b=UPkdxirGr+HslQwZfW7aZGsFIjX/hlnjhkEgIOZjSq/gGk0dL7x/rGp/35KCQTsyfi E0UcpVCn0e4A0Knks+0AXHnTnFHmXE2DUr8IBYqPIidXClhRwzHTU4SbMg/ccvpevDCn fn6oLBF8kAgU+lV2Ig2XWO1F2HOeFkgps4lxF/J5UzMZRDxETvMwBLRh69Z0NdDuPaA/ a2VnxY9l6w31IMeZC83IQyv8LQZOR7nisU+gLkg8Om2nuSpjIIjxx2Y7fwyEglqo4yxA dkPwsCnSOqabvbmxTAdhTazgU7qwobUmqv3awExjwmof94h7yFDxkOuB5ve84T3Yq3fl M6cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PeCBPDtNKEuaDKuiaHAzR3WaJUZOBwZPqqRsoj6cyhI=; b=fNL4Rc081wmCzi8xDMEn+yG8W8N5KTpSP7L478NE1EFug3DMhqdIanoTN65cOj9uFN ZiTFK5o6nIViKjV1HwF8s+KqmtLbuc3kjDm7JI6wlZhLchygyFqI/o7l5Yq5bzMsBEon yBdSkyiEWvBmiAFRdnD4VO36Kr78NJmkGFra6eDHBir04AC+XJplNe5ZHKHXUOqT4lUa aIgy3fkdHHOk4I+VvkszfU9fyq+4TrplSZiuR88lmt+fjjjOEn49ywWIZ5u8TcoKLKYd PlfZBA2s57ogGkJYrzRL9N0pZXCJzHCVVmvrMaiI8/5WImmDVYOgmdlThD3DlNTlnV0E 3Jrw== X-Gm-Message-State: AHQUAubzV7vjsA24OgboHFlWUgJ8fFxjsIlpMqg2l4aUNRVCbq9ncNuo RFp7PQhyAl2JnOv5jAClYHIKh9cqWH82ULVhg/gh+w== X-Received: by 2002:a19:5205:: with SMTP id m5mr4613271lfb.61.1550036764803; Tue, 12 Feb 2019 21:46:04 -0800 (PST) MIME-Version: 1.0 References: <20190201130519.GH20797@sirena.org.uk> <20190212122035.GA20635@sirena.org.uk> In-Reply-To: <20190212122035.GA20635@sirena.org.uk> From: Baolin Wang Date: Wed, 13 Feb 2019 13:45:53 +0800 Message-ID: Subject: Re: [PATCH 0/4] Add new device nodes for Spreadtrum SC9860 platform To: Mark Brown Cc: Arnd Bergmann , Rob Herring , Mark Rutland , Olof Johansson , Orson Zhai , Lyra Zhang , DTML , arm-soc , Linux ARM , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 Feb 2019 at 20:20, Mark Brown wrote: > > On Tue, Feb 12, 2019 at 04:40:10PM +0800, Baolin Wang wrote: > > On Fri, 1 Feb 2019 at 21:05, Mark Brown wrote: > > > > You can just list all the individual device names in the of_match_table > > > for the MFD and then it can bind to any of them. You can always map > > > them onto the same behaviour in the MFD driver if they are identical > > > from a software point of view. > > > If I understood correctly, as you suggested, we should add new > > mfd_cell groups to list all different PMICs' device names. Something > > like: > > I do think this is a good idea (registering the components of the MFD > using mfd_cell), though it wasn't quite the point I was making. Having > individual device names matters less for Linux-internal names like this. > > > But from my point, they are just some meaningless duplication, and > > will waste lots of code there. > > I was more thinking of the of_match table that has the IDs that appear > in DT - they're the one that's the ABI. Look at something like wm8994 > where the driver has several IDs listed in the main table then selects > function drivers based on that. Yes, we can use id_table to populate the PMIC child devices, but some child devices need use the device node to get some resources which are described in DT, so we must specify the of_compabible member of mfd_cell. That means we should use compatible string of the of_match_table to populate the child devices. So the problem is still there, we should expand the mfd_cell groups to list all device names, but just some meaningless duplication. -- Baolin Wang Best Regards