From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Subject: Re: [PATCH 1/2] dt-bindings: iommu/rockchip: Make clock properties optional Date: Tue, 17 Apr 2018 14:01:34 +0200 Message-ID: <5148367.G2SA8Hd4jl@phil> References: <20180410092612.2653-1-heiko@sntech.de> <2406273.dIyKc4zb8g@phil> <20180413210226.x4jx7b6kmui3oa3f@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180413210226.x4jx7b6kmui3oa3f@rob-hp-laptop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Rob Herring Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, tomeu-XCtybt49RKsYaV1qd6yewg@public.gmane.org List-Id: devicetree@vger.kernel.org Am Freitag, 13. April 2018, 23:02:26 CEST schrieb Rob Herring: > On Tue, Apr 10, 2018 at 01:26:41PM +0200, Heiko Stuebner wrote: > > Hi Robin, > > > > Am Dienstag, 10. April 2018, 13:18:48 CEST schrieb Robin Murphy: > > > On 10/04/18 10:26, Heiko Stuebner wrote: > > > > Rockchip IOMMUs are used without explicit clock handling for 4 years > > > > now, so we should keep compatibility with old devicetrees if possible. > > > > Therefore make iommu clocks optional. > > > > > > Do we need to touch the binding itself? Obviously the driver has to > > > treat clocks as optional in existing DTs (and I feel a bit dumb now for > > > managing to overlook that in review), but the binding effectively only > > > covers future DTs, and I'd assume we want to encourage the clocks to be > > > correctly specified there. > > I'd prefer the DT docs reflect what is correct for new/current dts > files. That's the only way the docs can validate the dts files. > > > I guess that depends on your definition of the timespan for backwards > > compatibility. I'm always starting out at indefinite till convinced > > otherwise ;-). Hence the clocks would need to stay optional for (nearly) > > forever. > > > > Also, having the binding claim them as required but the code handling > > them as optional just calls for someone to remove the optional handling :-D > > A comment in the code saying why missing clocks are allowed should > suffice. > > > Not sure if there is a established way of saying > > "we want this for all future devices, but allow it to be missing for old dts". > > We don't really... Ok, I'll drop the binding change and add a code comment then. Heiko