From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757237AbcAYOrh (ORCPT ); Mon, 25 Jan 2016 09:47:37 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:53870 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756600AbcAYOrb convert rfc822-to-8bit (ORCPT ); Mon, 25 Jan 2016 09:47:31 -0500 From: Arnd Bergmann To: Lee Jones Cc: xuejiancheng , mturquette@baylibre.com, sboyd@codeaurora.org, p.zabel@pengutronix.de, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, linux@arm.linux.org.uk, khilman@linaro.org, olof@lixom.net, xuwei5@hisilicon.com, haojian.zhuang@linaro.org, zhangfei.gao@linaro.org, bintian.wang@huawei.com, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, yanhaifeng@hisilicon.com, yanghongwei@hisilicon.com, suwenping@hisilicon.com, ml.yang@hisilicon.com, gaofei@hisilicon.com, zhangzhenxing@hisilicon.com, xuejiancheng@hisilicon.com Subject: Re: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl Date: Mon, 25 Jan 2016 15:45:38 +0100 Message-ID: <2693576.UgmARKQTGm@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160125142609.GR3368@x1> References: <1452219400-32478-1-git-send-email-xuejiancheng@huawei.com> <5675031.hi9rRCqFXs@wuerfel> <20160125142609.GR3368@x1> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:YroXXOMGrPCSasYYIR+zZhlhJIefZbOjD3XlM9WorDU2r8B+tpk QkpKGEQ2JWlzt1FP6cFMJHJwDvB6ba3SiUBAAHJ8SFlFvcmn2xkTPFeffAMFWWvNbQwB0an ebxkfVcY0oe/DkZCrwM0GxvOhO5EiVi0Vp6RpVz1xT3xC0RlEij1rpsBkC0MbgHctPAAAMk eZAQw0jwQM/OAScA2lMiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:+mbcOAdhTJo=:YJL7uTLE4m2mx/EaTcqvpp ZZC6mwXXIlgfXcSgSY6zvmpOAw8VdNevj39XbsQjFVP3rK+T85h8FwZfAw+agI94b3f7we+Ln Ee1PRT5ApADAUN6/4m/LwXISyOk9kxK8+vV2xEk0L0gIY3Q7eVCZidah+pSmIl4Mw68466xIU mqen8WobfinUEe9e0UEd2AkEZEAKVym3o8jFnUfmQtSRogskr2nsh5F0VHtekeKtfh6ali0v7 juYvOgvY7RihO2GfyJ2YbAskm2fhA7oRxhr5U80XHeJMISg8pHIkFVi/HxbDNEkf2WSWUti5i ZuRyimeuuqApLZBeQfdvv/jil7zcreLnTaWktR0PzmxM0LHyu9BHd5za1PVccKdw6YtslvR+F /zTgfMCY4EE0Tc0sWr/nppSFd2/AT0gVgXj7alPHCS0C52vp2OYvu1QkpSEtSwcSTM4SYUiPk fev3BuifnkSg0fK9czmeBt1g4KMQIR9HzOLsBCUZiAKYh9rqQ7tq5MZcfNFAMwQB84jRcqxLB mCU3WNvw4+a4D+VvSIBzs05Zp11mD0AeqWEiT52hAi+QNbIG9aGuti1yFLgsF6AwW1HVW7R0Y 1A9YzR0tifKuqQ7c2n/BNIM1r7IHn8EhotLKht8QPmyeJyPkeVYwDlfaEtxB7uziOxaEAVYEo eN9JRkDe8WnFco70q/tpzJqKeiSDdubRDkjAQqqOCgD+e3LpLZ1L/6FhqfMMpPwJOH25/0z8V QT8LCOeOlICwjMDZ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 25 January 2016 14:26:09 Lee Jones wrote: > On Tue, 12 Jan 2016, Arnd Bergmann wrote: > > > On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote: > > > >>>>> > > > >>>> Not yet. > > > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string > > > >>>> with the SOC name. This binding is just used for describing the compatible string now. > > > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also > > > >>>> needed. > > > >>> > > > >>> Save this binding until it has more functionality. We here "I'll add > > > >>> to this later" all too often. > > > >>> > > > >> > > > >> In the hi3519.dtsi file, there is a system-controller device node described like below: > > > >> sysctrl: system-controller@12010000 { > > > >> compatible = "hisilicon,hi3519-sysctrl", "syscon"; > > > >> reg = <0x12010000 0x1000>; > > > >> }; > > > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the > > > >> compatible string?　 > > > > > > > > Where is this compatible string _used_? > > > > > > > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding? > > > >> Could you give some suggestions? Thank you very much! > > > > > > > > If you're not using the compatible i.e. the device doesn't have its > > > > own driver yet, then there is no need to supply the binding at all, is > > > > there? > > > > > > > > > > OK. Thank you. > > > > > > > Sorry for stepping in late here. I still think that every syscon device should > > come with a specific compatible string, so we have the option of creating a > > driver later on, and I'd like to see a binding document that lists those strings > > (which I believe exists here). > > > > It's really hard to add compatible strings later on, anything else we can > > work around by keying off that string and adding a workaround in the kernel. > > Why is it more difficult (or any different) to add a compatible string > later (when it is used) over now (when it is not used)? There are many reasons why it can be hard to change a DT binary or source file later on. Sometimes the dtb is shipped with the firmware, sometimes someone has a slightly different platform that is not yet upstreamed, and they need to know about the change when forward-porting to a newer kernel. Either way, you always want to be able to run a newer kernel on an older dtb file without loss of functionality, so all "compatible" strings should generally be as specific as possible (with fallbacks to more generic strings). We do this even for devices that we think are identical, e.g. when multiple SoC vendors integrate the same IP block, but in this case, we already *know* that they are incompatible, so we should never have the same string as the most specific ID. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 25 Jan 2016 15:45:38 +0100 Subject: [PATCH v5 5/6] mfd: dt-bindings: add device tree bindings for Hi3519 sysctrl In-Reply-To: <20160125142609.GR3368@x1> References: <1452219400-32478-1-git-send-email-xuejiancheng@huawei.com> <5675031.hi9rRCqFXs@wuerfel> <20160125142609.GR3368@x1> Message-ID: <2693576.UgmARKQTGm@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 25 January 2016 14:26:09 Lee Jones wrote: > On Tue, 12 Jan 2016, Arnd Bergmann wrote: > > > On Tuesday 12 January 2016 17:28:05 xuejiancheng wrote: > > > >>>>> > > > >>>> Not yet. > > > >>>> Arnd Bergmann and Rob Herring all suggested adding a specific compatible string > > > >>>> with the SOC name. This binding is just used for describing the compatible string now. > > > >>>> When more functions on hi3519 SOC are added later, the specific driver will be also > > > >>>> needed. > > > >>> > > > >>> Save this binding until it has more functionality. We here "I'll add > > > >>> to this later" all too often. > > > >>> > > > >> > > > >> In the hi3519.dtsi file, there is a system-controller device node described like below: > > > >> sysctrl: system-controller at 12010000 { > > > >> compatible = "hisilicon,hi3519-sysctrl", "syscon"; > > > >> reg = <0x12010000 0x1000>; > > > >> }; > > > >> Do you mean that I should remove "hisilicon,hi3519-sysctrl" and just use "syscon" as the > > > >> compatible string?? > > > > > > > > Where is this compatible string _used_? > > > > > > > >> If I want to add "hisilicon,hi3519-sysctrl" for hi3519. where should I put this binding? > > > >> Could you give some suggestions? Thank you very much! > > > > > > > > If you're not using the compatible i.e. the device doesn't have its > > > > own driver yet, then there is no need to supply the binding at all, is > > > > there? > > > > > > > > > > OK. Thank you. > > > > > > > Sorry for stepping in late here. I still think that every syscon device should > > come with a specific compatible string, so we have the option of creating a > > driver later on, and I'd like to see a binding document that lists those strings > > (which I believe exists here). > > > > It's really hard to add compatible strings later on, anything else we can > > work around by keying off that string and adding a workaround in the kernel. > > Why is it more difficult (or any different) to add a compatible string > later (when it is used) over now (when it is not used)? There are many reasons why it can be hard to change a DT binary or source file later on. Sometimes the dtb is shipped with the firmware, sometimes someone has a slightly different platform that is not yet upstreamed, and they need to know about the change when forward-porting to a newer kernel. Either way, you always want to be able to run a newer kernel on an older dtb file without loss of functionality, so all "compatible" strings should generally be as specific as possible (with fallbacks to more generic strings). We do this even for devices that we think are identical, e.g. when multiple SoC vendors integrate the same IP block, but in this case, we already *know* that they are incompatible, so we should never have the same string as the most specific ID. Arnd