From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CD76C43334 for ; Wed, 5 Sep 2018 16:02:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E54862077C for ; Wed, 5 Sep 2018 16:02:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E54862077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ilande.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727758AbeIEUc5 (ORCPT ); Wed, 5 Sep 2018 16:32:57 -0400 Received: from chuckie.co.uk ([82.165.15.123]:58604 "EHLO s16892447.onlinehome-server.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbeIEUc5 (ORCPT ); Wed, 5 Sep 2018 16:32:57 -0400 Received: from host86-138-87-37.range86-138.btcentralplus.com ([86.138.87.37] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1fxaG0-0001pV-3R; Wed, 05 Sep 2018 17:02:19 +0100 To: Rob Herring Cc: Frank Rowand , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , David Miller , sparclinux@vger.kernel.org References: <20180830190523.31474-1-robh@kernel.org> <20180830190523.31474-4-robh@kernel.org> <35247ddc-303b-89d0-53b5-231c1a293721@gmail.com> <9c873e57-84c8-75af-1d44-60e7cd41282d@ilande.co.uk> From: Mark Cave-Ayland Openpgp: preference=signencrypt Autocrypt: addr=mark.cave-ayland@ilande.co.uk; keydata= xsBNBFQJuzwBCADAYvxrwUh1p/PvUlNFwKosVtVHHplgWi5p29t58QlOUkceZG0DBYSNqk93 3JzBTbtd4JfFcSupo6MNNOrCzdCbCjZ64ik8ycaUOSzK2tKbeQLEXzXoaDL1Y7vuVO7nL9bG E5Ru3wkhCFc7SkoypIoAUqz8EtiB6T89/D9TDEyjdXUacc53R5gu8wEWiMg5MQQuGwzbQy9n PFI+mXC7AaEUqBVc2lBQVpAYXkN0EyqNNT12UfDLdxaxaFpUAE2pCa2LTyo5vn5hEW+i3VdN PkmjyPvL6DdY03fvC01PyY8zaw+UI94QqjlrDisHpUH40IUPpC/NB0LwzL2aQOMkzT2NABEB AAHNME1hcmsgQ2F2ZS1BeWxhbmQgPG1hcmsuY2F2ZS1heWxhbmRAaWxhbmRlLmNvLnVrPsLA eAQTAQIAIgUCVAm7PAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQW8LFb64PMh9f NAgAuc3ObOEY8NbZko72AGrg2tWKdybcMVITxmcor4hb9155o/OWcA4IDbeATR6cfiDL/oxU mcmtXVgPqOwtW3NYAKr5g/FrZZ3uluQ2mtNYAyTFeALy8YF7N3yhs7LOcpbFP7tEbkSzoXNG z8iYMiYtKwttt40WaheWuRs0ZOLbs6yoczZBDhna3Nj0LA3GpeJKlaV03O4umjKJgACP1c/q T2Pkg+FCBHHFP454+waqojHp4OCBo6HyK+8I4wJRa9Z0EFqXIu8lTDYoggeX0Xd6bWeCFHK3 DhD0/Xi/kegSW33unsp8oVcM4kcFxTkpBgj39dB4KwAUznhTJR0zUHf63M7ATQRUCbs8AQgA y7kyevA4bpetM/EjtuqQX4U05MBhEz/2SFkX6IaGtTG2NNw5wbcAfhOIuNNBYbw6ExuaJ3um 2uLseHnudmvN4VSJ5Hfbd8rhqoMmmO71szgT/ZD9MEe2KHzBdmhmhxJdp+zQNivy215j6H27 14mbC2dia7ktwP1rxPIX1OOfQwPuqlkmYPuVwZP19S4EYnCELOrnJ0m56tZLn5Zj+1jZX9Co YbNLMa28qsktYJ4oU4jtn6V79H+/zpERZAHmH40IRXdR3hA+Ye7iC/ZpWzT2VSDlPbGY9Yja Sp7w2347L5G+LLbAfaVoejHlfy/msPeehUcuKjAdBLoEhSPYzzdvEQARAQABwsBfBBgBAgAJ BQJUCbs8AhsMAAoJEFvCxW+uDzIfabYIAJXmBepHJpvCPiMNEQJNJ2ZSzSjhic84LTMWMbJ+ opQgr5cb8SPQyyb508fc8b4uD8ejlF/cdbbBNktp3BXsHlO5BrmcABgxSP8HYYNsX0n9kERv NMToU0oiBuAaX7O/0K9+BW+3+PGMwiu5ml0cwDqljxfVN0dUBZnQ8kZpLsY+WDrIHmQWjtH+ Ir6VauZs5Gp25XLrL6bh/SL8aK0BX6y79m5nhfKI1/6qtzHAjtMAjqy8ChPvOqVVVqmGUzFg KPsrrIoklWcYHXPyMLj9afispPVR8e0tMKvxzFBWzrWX1mzljbBlnV2n8BIwVXWNbgwpHSsj imgcU9TTGC5qd9g= Message-ID: Date: Wed, 5 Sep 2018 17:01:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 86.138.87.37 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk Subject: Re: [PATCH 3/3] of: make default address and size cells sizes private X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/09/18 13:12, Rob Herring wrote: > On Tue, Sep 4, 2018 at 11:59 PM Mark Cave-Ayland > wrote: >> >> On 05/09/18 02:55, Frank Rowand wrote: >> >>> On 08/30/18 12:05, Rob Herring wrote: >>>> Only some old OpenFirmware implementations rely on default sizes. Any >>>> FDT and modern implementation should have explicit properties. Make the >>>> OF_ROOT_NODE_*_CELLS_DEFAULT defines private so we don't get any outside >>>> users. >>>> >>>> This also gets us one step closer to removing the asm/prom.h dependency on >>>> Sparc. >> >> Just for the record: you say "any FDT and modern implementation should >> have explicit properties", however the default values of these >> properties when missing are clearly defined in the IEEE-1275 >> specification (Annex A): > > The spec may define defaults, but best practice is to be explicit. For > FDT, dtc doesn't allow defaults (and never has). No arch added in the > last 10 years has relied on the defaults. > >> "#address-cells" >> Standard property name to define the package’s address format. >> ... >> In a package with a "decode-unit" method, a missing "#address-cells" >> property signifies that the number of >> address cells is two. > > So only Sparc is compliant as the default for everyone else is 1. > >> "#size-cells" >> Standard property name to define the package’s address size format. >> ... >> A missing "#size-cells" property signifies the default value of one. >> >> I can't speak for FDT but it isn't completely unreasonable for a guest >> parsing a DT without these properties to assume these default values. > > I'm not removing the defaults. Just not allowing for code outside of > drivers/of/ to use the defaults. Got it - if dtc requires explicit properties, then I agree there should be no issues with this patch. Sorry for the noise. ATB, Mark. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Cave-Ayland Date: Wed, 05 Sep 2018 16:01:52 +0000 Subject: Re: [PATCH 3/3] of: make default address and size cells sizes private Message-Id: List-Id: References: <20180830190523.31474-1-robh@kernel.org> <20180830190523.31474-4-robh@kernel.org> <35247ddc-303b-89d0-53b5-231c1a293721@gmail.com> <9c873e57-84c8-75af-1d44-60e7cd41282d@ilande.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Rob Herring Cc: Frank Rowand , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , David Miller , sparclinux@vger.kernel.org On 05/09/18 13:12, Rob Herring wrote: > On Tue, Sep 4, 2018 at 11:59 PM Mark Cave-Ayland > wrote: >> >> On 05/09/18 02:55, Frank Rowand wrote: >> >>> On 08/30/18 12:05, Rob Herring wrote: >>>> Only some old OpenFirmware implementations rely on default sizes. Any >>>> FDT and modern implementation should have explicit properties. Make the >>>> OF_ROOT_NODE_*_CELLS_DEFAULT defines private so we don't get any outside >>>> users. >>>> >>>> This also gets us one step closer to removing the asm/prom.h dependency on >>>> Sparc. >> >> Just for the record: you say "any FDT and modern implementation should >> have explicit properties", however the default values of these >> properties when missing are clearly defined in the IEEE-1275 >> specification (Annex A): > > The spec may define defaults, but best practice is to be explicit. For > FDT, dtc doesn't allow defaults (and never has). No arch added in the > last 10 years has relied on the defaults. > >> "#address-cells" >> Standard property name to define the package’s address format. >> ... >> In a package with a "decode-unit" method, a missing "#address-cells" >> property signifies that the number of >> address cells is two. > > So only Sparc is compliant as the default for everyone else is 1. > >> "#size-cells" >> Standard property name to define the package’s address size format. >> ... >> A missing "#size-cells" property signifies the default value of one. >> >> I can't speak for FDT but it isn't completely unreasonable for a guest >> parsing a DT without these properties to assume these default values. > > I'm not removing the defaults. Just not allowing for code outside of > drivers/of/ to use the defaults. Got it - if dtc requires explicit properties, then I agree there should be no issues with this patch. Sorry for the noise. ATB, Mark.