From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754403AbbL3JaU (ORCPT ); Wed, 30 Dec 2015 04:30:20 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:61671 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754198AbbL3J3r (ORCPT ); Wed, 30 Dec 2015 04:29:47 -0500 From: Arnd Bergmann To: Rob Herring Cc: Michael Turquette , Olof Johansson , Eric Anholt , linux-clk , "Stephen Boyd , Emilio Lopez , Hans de Goede , linux-clk , linux-arm-kernel" , linux-rpi-kernel@lists.infradead.org, Linux Kernel Mailing List , Stephen Warren , Lee Jones , Florian Fainelli , Stephen Boyd , "devicetree@vger.kernel.org" Subject: Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates. Date: Wed, 30 Dec 2015 10:29:02 +0100 Message-ID: <1477432.fTm0GUZ57A@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1450222559-22461-1-git-send-email-eric@anholt.net> <20151228223935.25842.28675@quark.deferred.io> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:s0RWDhOu29lODNTM9Z0FTUph+Kepc/gYyvmflEaZUd1aJK9dJOO tlv9BDUS8iy1e+FeJWsoMc4N0XCECn+luDUtmYScYhBmu8WuLLMgMoQTeKTlpxIDCDYZs07 qAGvLvHpXP72TyJHsWQCGTNQdcsE+6DAOEKdLIzx/2BmPb/Mwh4JpuGooShneb6s6FOwI3k L4wqV0usTIq6wqde6A5WQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:mwA6kOoQd94=:4J9RawHgjd9LKjY4WKwv/R TkRiR2EHvgQ4QJrZHOGQyT+oy6A6aS/QG4pkFFnDc+YD4g1xMWo1g6CE5T7m7ofqnv5ABxJht vhn5XcX64Ma9CgtpVg2YPj+i3h1mbIPICX4bduGZhXoF88eR8hY9FbtpfBkyw1s0/sFYn7SDI ixT0PLKbEPWtr1bASiET4j7H/MVjll1u4od52Qk2sTtC5gz1T4aU2ZCeeGDBikHqWlaM+kQ3W Rdn7HmSKAQIL+wKRYL5M0kWzhfYtvRlNg7StY9urp6R9uoG0HVq/6ysXJcm/cgJ0xKLK9dBie rmm5q06LIGGT8DexoGTkDyKSrulWvuKsqHI9fbQofQWBJCeifQYSz2MxI/3/xcHB5sZaAqn+4 KcBwgbxEXGUYN+gi/ux1I3B9rvL0Gs/I/YAqZR7a0VelM10Ea+PpUJc0tYFnQICfsIFe1MFUs R66zEolOtgd1fcomaMfWFzui9H0tkjJiG5VYbiAVUD1psRAcXbo+/h9exjVbYFaHugkWdf/xG iKxLWK6jmKP836u5o76bq/E8dJ7Xqye/MkW9RjlLemVJbRDzcIBeJbdNuI6MD8a3Ljb0sANYg 8pl7QaL11uZau6mw0nyjOkqqtYpEMpo+gvoN84QoVjs+2gzRdoPorICwh4V35HdLdQtHEnp11 v10i6ueFBFCp2atV9jw7+0LX8vGUhWL0g9UdHuLFR8WyOn7W+313NXOwDkiw/1oIhjD8Wu7eP SZL9nkjfoN9uD5w0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 29 December 2015 16:15:09 Rob Herring wrote: > On Mon, Dec 28, 2015 at 4:39 PM, Michael Turquette > wrote: > > Quoting Eric Anholt (2015-12-24 15:45:15) > >> Michael Turquette writes: > >> I would *love* to do that, but I've previously been told that having the > >> bindings patch reference a header file not present as of the bindings > >> patch is not acceptable and made to change it. > > > > Ugh, that is annoying. I would think that having code compile properly > > would trump the desire to have all of the documentation merged as one > > patch. > > What about compiling the dts? > > > On the other hand, I've been asked to not take binding descriptions > > through the clk tree. That is a policy that I'm happy to comply with, > > but it is at odds with the recommendation for the header and the binding > > description to be merged together. > > By who? Any bindings in a series I always expect the subsystem > maintainers to take the whole series. That doesn't solve the problem > though as there is still a dependency between a subsystem tree and > arm-soc typically. I don't care too much which tree the binding description goes through either, as long as it is kept in sync. > > DT folks, what is the right way to do this? An immutable, shared branch > > just for a single header file solves the problem, but also feels very > > cumbersome for such a trivial issue. > > Arnd and Olof have been complaining about this problem which is worse > when it is a binding, driver and dts. > > I'm open to maintaining a branch for this purpose if that helps. That > or staggering merging of bindings and drivers/dts are the only ideas > I've come up with. > > How about allowing binding descriptions to be merged without the header > > file, so long as it is merged through another tree? > > I think that is wrong if we have the goal to separate bindings from > the kernel and the bindings should stand on their own. However, if it > greatly simplifies things, i'd be okay with that. The header file is really the main issue we need to worry about. My preferred way of doing this would be to give it an extra merge window: add the binding document and the header file in one merge window, and then add the dts files and the driver one release later. I've seen a lot of header files added for no good reason at all, and at least that way we can get people to think about the dependency more. It's also ok to merge the header file and binding with either the dts file changes or the driver and then do the other part the following release. In the past, we've worked around the issue by merging the driver through arm-soc, or by merging the dts changes through a driver tree, with the appropriate Acks in each case. Both of those approaches work of course, but the former always feels awkward to me as we are not using the right maintainer path, and the latter approach tends to cause merge conflicts, especially when multiple headers for different subsystems get added or the dts files are added at the same time. Having a shared branch for the header file is another way to do it, and we can do that in some cases, but I'd prefer not to make it the default. Arnd