From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756882AbcGGITo (ORCPT ); Thu, 7 Jul 2016 04:19:44 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:60086 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756662AbcGGITi (ORCPT ); Thu, 7 Jul 2016 04:19:38 -0400 From: Arnd Bergmann To: John Stultz Cc: Olof Johansson , lkml , "arm@kernel.org" , Michael Turquette , 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:22:30 +0200 Message-ID: <4270415.JTHdGZyKEo@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:K5J9TJ5dGNU+XgO8KXh7goftyCAerDiz3Xc9pY5Y+0vAG8tOSrV r3+HWelJPN9arTLLCuBIC36P0wG4S9xeugM4rE2DvLmMkvxUYcFf1jDTqKL+crCNnBUxOf3 uXKd3Yr85OAa9B1V45KJq2YjKCUno4sW96xMjBqJyGpp3InqVtFsA7geYg4qYFJfAaXkKek SXyMjO6iTSg993PZPxZSQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:T+B3Qa2awYI=:Pmv4kDDl/V7zKk4RMBJWQn 6yqpmZ1wJn5E6hLUZR4go1hYHRVRRSxjYruyhhVMy7lYBrpgQNBCnhmFP4X5xNrHu6kQuqLPQ qNQXLaA0S68RJ+qPoeriNj5pdrXlsgY3rc20ZRjrvH5JiGeQXxAJ6dVTJ1Kwql+Z8g97g+VLA WwZ0JCxPPScq4dVUBG9vVe+QbYuEyOmj2kC/nh7ARjjfoHqv5g+dJ69958zQ5VSsOGD2KCFpQ +xNtJHXRWqc7Ey+7jyIvXFygVK5Qh6M1sa6fNsmPVLAN/Y1/Qqb0DmsX+dxIgVK0FnMMRRS/r ruwj+Gp0cTEePNBzZrDN4E1HLwNZ7ywFW2aPkpE7Xblv6s+TRu6OOmGlXYb5lbGMC8MIXlWCE ZeCyWYlJUyok4X942U6J+Lr6XAYQJCOT2C1l3YlJfHRAXHSyXFSqs0GwxYYQVcCZXlo/3eDpP dB6Coze6VMwR+V5VBdJGAQTdNq3IMDsR8/vEp0nle/FqEuqMrWGUVKEbO2XqBNLRtUhqq0cDN mJrh0cp8wIZo/hdCssL2um4C3jdhTr3Y5qghrF9xCSCqfJDKVTBBRkGTbdNO2kYartsvXichC AhsWnsDujDp8iA6Syf5IZdqoWz2U+v5q29cBz4ZS6H8TORRCHwGYiQDLbUCfXHGlN9Nv46cZL bCQ/jFS/IgdwfG78YDtqtWmHFw2aSo6Pa0Ak0HoKnOVp6X+7B/hhWpPI9aHcxgmHXN7fOeu9f iixaPgNQuZeEsHA4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, July 6, 2016 5:58:14 PM CEST John Stultz 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: > > Though this seemingly goes against the otherwise widely recommended > approach of breaking up patches into small obvious chunks. > > And personally, and I don't mean to criticize, but the suggestions > here (use numerical values, then later rename to macros; add > everything in one go, then make dts changes a release later) all seem > like non-optimal workarounds for the fact that adding almost any > functionality requires cross subsystem-maintainer negotiations (or two > release steps to get one bit of functionality merged). > > It seems like it might even just be clearer to make the > two-release-steps method the widely broadcast rule (ie: no > dependencies on in-flight patches for dts changes), so this doesn't > confuse/dismay new developers. > > Anyway... In this case, I don't have the clk documentation, so I'll > ping Zhangfei to check if there is any other clock values that should > be added in the future, but at least for HiKey, while there are still > a few clk patches remaining in the tree, I don't have any more > additions to the clk list. I think the main underlying problem is hardware that is so badly structured that there is no way to describe it other than to enumerate each output in a header file and have a separate handler in the driver for it. We typically have it easier for other subsystems like irqchip or gpio where nobody would consider writing a driver that can only handle the I/O lines that are used on their board with a minimal set of drivers, but for some reason it seems acceptable to do it for clock controllers just because they are harder to describe. For the common case where the driver developer actually has a description of the clock controller hardware in a manual, I see no reason not to implement the complete driver right away. Arnd