From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030489AbcGGILS (ORCPT ); Thu, 7 Jul 2016 04:11:18 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:57607 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030197AbcGGILF (ORCPT ); Thu, 7 Jul 2016 04:11:05 -0400 From: Arnd Bergmann To: Michael Turquette Cc: John Stultz , Olof Johansson , lkml , "arm@kernel.org" , Stephen Boyd , Rob Herring , Pawel Moll , Wei Xu , Guodong Xu , Zhangfei Gao Subject: Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220 Date: Thu, 07 Jul 2016 10:13:58 +0200 Message-ID: <4291679.2tyPNCYhyb@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1467247725-3665-1-git-send-email-john.stultz@linaro.org> <3989688.6Bh7v9havA@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:lp0p80BoSn9po2Cr0KidCW0u96PjMjbNKfNCT8UsPswjRUtSF1/ JUB1+QQL82hc4XBO80e9wkujdOaybcn2mLBp3JUmX1uTuf4f+K/Llu5BRiWLZ+w2sYppPue Ej/Vl21nGhGzo/m+y9sb02MkLXoAfDlb8MDStXvPycTpyuUQzU18p5EPtpVvRMyaWnveYeh 5FXAimLrx/Chrd9+LgAmA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Cqg8W32jirI=:t3MF/opSyrXf8eq3+gx53U k+sudAvOObVma8pjOIVVEoZCsPeiMvCYmRyWN0ZQosJ6j+0TukayaHze1I7UiDEm3pcBdKk2M 5mc3N2FvLYmrfxvlUsYiEpRiPAxnrA6hpy0gyQKrnOTJk5ujfusWfCAm+Vnj3A0PR5XU2YR4T Xmff/rJY4Tpi4DuHGMNZ8n2O9xW+r69GnFw+MQcprTeXW7tdLM7CeWmYD9b9rmR4p/l/vQF8m +xozUoxeMBoXNucTeGzJEQbWFwskwKAWMRoOm0iTHB3rwn2XjUyAYDw9pJyU8e/gqqwNX3bqQ Ul8tOx5ZqQ8Ofd9sbeXYqb1Xl5PvJCdu3SImIBwmBBj1nvOmtDyo7VlswZ8S4daW4wKge4Yq8 lja7AGQ3MmAaJ0ZWJRep4RIoJz5ShQ1gJyN2L9iLLwIME6Tyckmv/XUG4QM6tv7bsWcVOuiAg ekh/Y3lYrB8/z24Hkay6srNQeyb1lML6Ayz+g3P+lnVU9kHCYksDYCeKezP5e0crWYsJTYzf9 65880zmnN2JVVZZSmaB6m8CpyNL2vavmDtGjK2PSPE+r+mAUj2t9iIqvaxd2Bmsfziy3oGKIi 5ROSRUHGOvtZ5nB3RwpBCkPzMl7v0ujeZ0X6Q8ew/v4p87CqNsISUXXngQueBeZX2a6n7eij8 JRYSHbOmAqbY7GHwn14NznFL/jmjbhkaHDoR0pfEOz4l8l8+6wMMtvX5Epz/BcITq3aQt38gA sZrds+tBvknxVeS0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, July 6, 2016 5:19:53 PM CEST Michael Turquette wrote: > On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann wrote: > > > > On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote: > > > On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson wrote: > > > > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz wrote: > > > >> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson wrote: > > > >>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote: > > > >>>> This patchset enables the pl031 RTC on the Hi6220 SoC. > > > >>>> > > > >>>> I'd like to submit it to be merged. > > > >>>> > > > >>>> Wei has acked the second patch (modulo a whitespace fix which > > > >>>> I've included in this v3), so it seems like both could go > > > >>>> through the clk tree. > > > >>>> > > > >>>> But Wei also seemed open to pulling in a clk tree branch > > > >>>> as it goes through arm-soc. > > > >>>> > > > >>>> Michael/Stephen: If there's no other objections, could you > > > >>>> queue the first patch and make it avilable via the branch for > > > >>>> Wei, or just take both patches? > > > >>> > > > >>> I happen to dread these kind of patchsets these days. There's added > > > >>> dependencies across trees just because a defined name for the clock > > > >>> number is added to a header file. > > > >>> > > > >>> I much prefer to use numerical clocks for one release, and then once > > > >>> everything is in, switch over to the defines in the DTS. > > > >>> > > > >>> That way there are no dependencies, no need to setup a shared branch > > > >>> for a simple 3-line patch, etc. > > > >>> > > > >>> So, mind respinning the DTS piece? > > > >> > > > >> Huh.. > > > > > > > > Sorry if it appeared random, I've complained about it for a while to > > > > submaintainers. > > > > > > No.. I get it, the cross-maintainer shared branch is complex enough to > > > want to avoid. I figured it would be easier to just take a maintainer > > > acked patch in via the clk tree, but its not my tree, so I'll leave it > > > to you maintainers to resolve. > > > > The question this raises is why that clock was missed the first time > > around. I'd suggest whoever owns the clock driver can go through the > > documentation again and look for others that may have been missed, > > then send a patch to the driver to add *all* the missing ones for the > > merge window, and one release later we add the driver depending on > > previously unknown clocks. > > Well, I'm kicking the ant pile on this one, but sometimes the above > suggestion is not possible. I'm currently hacking on a platform with > very limited docs, so I cannot understand the whole clock tree, nor > how all peripherals are wired up to it. That's clearly not the case here though: the hi6220 clk driver was contributed by hisilicon engineers that have all the documentation. > Further complicating matters is that fact that any headers in the DT > include chroot constitute an unbreakable ABI that shall stand for > 1,000 years at least, so I'm very remiss to dump a bunch of constant > values in there with names that might need to change at a later date. Can you give an example why they might need to change? Usually the hardware doesn't change. There is also a risk of having a driver binding that makes sense for the first 10 clocks that get added, and then it later turns out that the chip actually has hundreds of clocks that could really use a completely different binding to allow a simpler driver. Arnd