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 813FCC433FE for ; Mon, 3 Oct 2022 09:04:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231235AbiJCJEw (ORCPT ); Mon, 3 Oct 2022 05:04:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230235AbiJCJEZ (ORCPT ); Mon, 3 Oct 2022 05:04:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B12B1B9D4; Mon, 3 Oct 2022 01:57:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 30A5560FDC; Mon, 3 Oct 2022 08:57:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5C5FC433D6; Mon, 3 Oct 2022 08:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664787453; bh=Q0+10uGkL4axbW9qxQGcxfGVVKx4pZGFzgy/AdKF73U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uYu775RSi0HNcBsbUBsldRx0yfp5zZhNk9iw2RF6zjr8RsiwQmNKL38pJt6GyQpue oVTr3dzXpHysEBSagVi/PH/J8B3G0m2R118es6dRaCnqVUbj2zOJ0wiJhD9NH2nq1D Ey544VUEVKMN6uSyZkS0QAyiAXqZSbktx/4XGZ+Gx4YDTimA5ZswpFAbl31VNft/Ap xPocBUZI6AMCTLLrWmFTQ7xGgN9QAyCcTIboz+ocvQOdSZG6s07i1zs/+PSbJwd5tu GaqwUnqK9tRdVwWSv2zCNXWzcxYkVWq0zi1V+arWCjPsVWmRqoyM6W6umIX7jv5Hfn boy2PCKTheFSA== Date: Mon, 3 Oct 2022 09:57:27 +0100 From: Lee Jones To: Biju Das Cc: Rob Herring , Krzysztof Kozlowski , Thierry Reding , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , "linux-pwm@vger.kernel.org" , "devicetree@vger.kernel.org" , Geert Uytterhoeven , Chris Paterson , Biju Das , Prabhakar Mahadev Lad , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: Document RZ/G2L MTU3 PWM Message-ID: References: <20220929103043.1228235-1-biju.das.jz@bp.renesas.com> <20220929103043.1228235-4-biju.das.jz@bp.renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Mon, 03 Oct 2022, Biju Das wrote: > Hi Lee, > > > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: Document > > RZ/G2L MTU3 PWM > > > > On Sat, 01 Oct 2022, Biju Das wrote: > > > > > Hi Lee Jones, > > > > > > > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: Document > > > > RZ/G2L MTU3 PWM > > > > > > > > On Thu, 29 Sep 2022, Biju Das wrote: > > > > > > > > > Hi Lee Jones, > > > > > > > > > > Thanks for the feedback. > > > > > > > > > > > Subject: Re: [PATCH RFC 3/7] dt-bindings: mfd: rz-mtu3: > > Document > > > > > > RZ/G2L MTU3 PWM > > > > > > > > > > > > On Thu, 29 Sep 2022, Biju Das wrote: > > > > > > > > > > > > > Document RZ/G2L MTU3 PWM support. It supports following pwm > > > > modes. > > > > > > > 1) PWM mode 1 > > > > > > > 2) PWM mode 2 > > > > > > > 3) Reset-synchronized PWM mode > > > > > > > 4) Complementary PWM mode 1 (transfer at crest) > > > > > > > 5) Complementary PWM mode 2 (transfer at trough) > > > > > > > 6) Complementary PWM mode 3 (transfer at crest and trough) > > > > > > > > > > > > Shouldn't all this go in the PWM driver binding? > > > > > > > > > > Looks like at top level MTU3 IP provides similar HW > > functionality > > > > like > > > > > below binding [1], where there is a core MFD driver and pwm, > > > > > counter and timer as child devices. > > > > > > > > Previous mistakes are not good references for what should happen > > in > > > > the present and the future. =;) > > > > > > Why do you think that reference is not a good one? I believe there > > > should be some reason for it. > > > > I didn't even look at it. > > > > What I "believe" is that documentation for each functionality > > belonging to a particular subsystem should live in subsystem's > > associated documentation directory and be reviewed/maintained by that > > subsystem's associated maintainer. > > If I am correct, MFD is subsystem for calling shared resources > across subsystems. > > Here shared resources are channels which is shared by timer, counter and pwm Which API do the consumers use to obtain these shared resources? > They are child objects of MFD subsystems. That is the reason it is in MFDndings. If the properties belong to the child, they should be documented in the child's bindings. Shoving all functionality and by extension all documentation into the MFD driver and/or binding is incorrect behaviour. Looking at it from another perspective, I cannot/should not review PWM, Reset, Counter or Timer bindings, since I do not have the level of subject area knowledge as the assigned maintainers do. Please place all sub-system specific bindings in their correct (leaf) bindings and link to them from this one (run this): git grep \$ref -- Documentation/devicetree/bindings/mfd/ -- Lee Jones [李琼斯]