From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA07CC6FA86 for ; Thu, 22 Sep 2022 10:19:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230329AbiIVKTZ (ORCPT ); Thu, 22 Sep 2022 06:19:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229743AbiIVKTQ (ORCPT ); Thu, 22 Sep 2022 06:19:16 -0400 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2883EDCCE4 for ; Thu, 22 Sep 2022 03:19:12 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id o5so6464862wms.1 for ; Thu, 22 Sep 2022 03:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Ju6BSMep2KJyGnXzsed5+vjZslhWJvx3S4Wq5/v4xCw=; b=SUzZ8/4LQ4z00agprzqQeqMQLmjUXi2wsNvMkS8ormVPl6wY8bqlkFmPrSOEZLelmN Qz7hfA5Me6aZW1tPo3cjvgDzPdn94oBcjCv3CCyOO8iVWqve6ksrMFi4slrgPXRK+1PZ +u3ITed68JlvQLhmeUkCjPh4qYLfkzNsyk8BZyWNo6qii9435XtirTue6McBo9COeZTe XAG1B0zphCcLCRCXNmFUYjWKppoQ3zdqPcXpnd3etpE8iY3PzVE1lGn7m0xRAox5B1rj zOep1puhY+R4piUYjcxzwW9UeyQqtnbtu4U6+scj0oED1JQk4uofgsAggHeNDVcV3l9d Dohg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Ju6BSMep2KJyGnXzsed5+vjZslhWJvx3S4Wq5/v4xCw=; b=U9rbQe71vVIYtL9lTdesnzXZqnmwOyl3mhXAOpdIJkfWGnu6ED7PV//OvxDxws+QFc b62X47r/Q0p0NWhpBuWGqKluOkb7/PvGLinv93TxVrNqd046bl9or7LNhqwyll+xsHR4 KQXgnu40FsiF+GJuihTgozBs7P51/pauFANitzccuvpE6LQ9PEgL3IvdftsvyP3+NJ9R INvHwyFx3z1B1cDIqz/1zHslsl48/L8ZMFfmq5zGr/ygb32sjrFdhZxtohPFiPqiQFjU ZM/FGhzZNFOHSGBAhjOj9gy0cRNtBe4KK5WKM+WMl8HKi70JneQTy/4j96JplSZdLwYx 6EbQ== X-Gm-Message-State: ACrzQf36MQxZBpdx3VNh0kVVApmaOoDRfZThsSTZJUl2mLAUivZ9YyP9 pdaVxWA5yxHa6og6j9mxLCoroQ== X-Google-Smtp-Source: AMsMyM4OscS0C1jykeo4QICxF2cHBCMYygPB7nFReh7fcMsWjdX9Dluta8CohpeAWrA95czQeAow/w== X-Received: by 2002:a05:600c:42d4:b0:3b3:3de1:7564 with SMTP id j20-20020a05600c42d400b003b33de17564mr1831131wme.152.1663841950631; Thu, 22 Sep 2022 03:19:10 -0700 (PDT) Received: from google.com (cpc155339-bagu17-2-0-cust87.1-3.cable.virginm.net. [86.27.177.88]) by smtp.gmail.com with ESMTPSA id c17-20020a7bc851000000b003b47575d304sm6500817wml.32.2022.09.22.03.19.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Sep 2022 03:19:10 -0700 (PDT) Date: Thu, 22 Sep 2022 11:19:08 +0100 From: Lee Jones To: Chunyan Zhang Cc: Mark Brown , Liam Girdwood , Rob Herring , devicetree@vger.kernel.org, Baolin Wang , Orson Zhai , Chunyan Zhang , LKML , Lee Jones Subject: Re: [PATCH v2 2/2] dt-bindings: regulator: Add bindings for Unisoc's SC2730 regulator Message-ID: References: <20211008031953.339461-1-zhang.lyra@gmail.com> <20211008031953.339461-3-zhang.lyra@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, 22 Sep 2022, Chunyan Zhang wrote: > Hi Mark, > > Sorry for the late response. > [1] is the v1 on which we had some discussion. I hope that can help > recall the issue below. > > On Fri, 12 Nov 2021 at 21:46, Mark Brown wrote: > > > > On Fri, Oct 08, 2021 at 11:19:53AM +0800, Chunyan Zhang wrote: > > > > > +properties: > > > + compatible: > > > + const: sprd,sc2730-regulator > > > > I still don't understand why this MFD subfunction for a specific device > > is a separate binding with a separate compatible string, the issues I > > mentioned previously with this just encoding current Linux internals > > into the DT rather than describing the device still apply. > > I understand your point. But like I described previously [1], if we > still use the current solution (i.e. use devm_of_platform_populate() > to register MFD subdevices), a compatible string is required. I'm open > to switching to other solutions, do you have some suggestions? Many IPs encompassing multiple functions are described that way in DT. I don't have the details for *this* device to hand, so my comments here aren't specific to this use-case, but describing each function individually does describe the H/W accurately, which is all DT calls for. Can you imagine describing an SoC, which can be considered as a huge MFD, with only a single node? Does the regulator functionality have it's own bank of registers? -- DEPRECATED: Please use lee@kernel.org