From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755812AbcHXO3I (ORCPT ); Wed, 24 Aug 2016 10:29:08 -0400 Received: from smtpoutz298.laposte.net ([178.22.154.198]:56989 "EHLO smtp.laposte.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753488AbcHXO3G (ORCPT ); Wed, 24 Aug 2016 10:29:06 -0400 To: devicetree@vger.kernel.org, LKML , Linux ARM Cc: Mason From: Sebastian Frias Subject: ARM,SoC: About the use DT-defined properties by 3rd-party drivers Message-ID: <57BDAF2E.10502@laposte.net> Date: Wed, 24 Aug 2016 16:29:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-VR-SrcIP: 78.31.43.6 X-VR-FullState: 0 X-VR-Score: 0 X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrfeeluddrfeeigdejjeculddtuddrfeeltddrtddtmdcutefuodet X-VR-Cause-2: ggdotefrodftvfcurfhrohhfihhlvgemucfntefrqffuvffgnecuuegrihhlohhuthemucehtddtnecu X-VR-Cause-3: necujfgurhepvffhuffkffgfgggtgfesthejrgdttdefjeenucfhrhhomhepufgvsggrshhtihgrnhcu X-VR-Cause-4: hfhrihgrshcuoehsfhekgeeslhgrphhoshhtvgdrnhgvtheqnecukfhppeejkedrfedurdegfedrieen X-VR-Cause-5: ucfrrghrrghmpehmohguvgepshhmthhpohhuthdphhgvlhhopegludejvddrvdejrddtrddvudegngdp X-VR-Cause-6: ihhnvghtpeejkedrfedurdegfedriedpmhgrihhlfhhrohhmpehsfhekgeeslhgrphhoshhtvgdrnhgv X-VR-Cause-7: thdprhgtphhtthhopeguvghvihgtvghtrhgvvgesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-VR-AvState: No X-VR-State: 0 X-VR-State: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Given a SoC and its SDK, 3rd party users of said SoC (customers of the SoC's manufacturer) may need/want to write kernel modules. Since the DT describes the HW, it would make sense to expose some HW properties through the DT, and have 3rd party users rely on them to write their drivers in a generic way. However, it seems that one is not allowed to upstream DT bindings and properties without a driver, is that right? If true, that hampers DT usage by out-of-tree drivers (or in this case, drivers that are not written yet) and limits the usage of DT properties as an API. We can understand that DT maintainers want to know what goes upstream, make sure that the bindings are documented, that there are no conflicts with other bindings or generic strings, etc. However, it is hard to see why there is not a "relaxed" upstreaming path for SoC-specific properties (i.e.: that do not affect DT API nor other SoCs). As an example, we would like to add some properties to /soc/ like: soc { compatible = "simple-bus"; ... sigma-register-layout-version = <2>; sigma-has-XYZ-capability; and so on. If this is really not possible, it forces the SoC manufacturer to expose those properties in a different way, thus wasting a (seemingly) perfectly fine way of doing so: the DT and its documentation. Thoughts? By the way, what about properties generated on-the-fly by the bootloader? Thanks in advance. Best regards, Sebastian