Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp7202351rwr; Tue, 25 Apr 2023 09:24:40 -0700 (PDT) X-Google-Smtp-Source: AKy350YVtpMirukni93slRw0GySu9BBDcDNpNH9/PXkULQoGvM9MOlARx8sV96JYbRLi62ciWsQb X-Received: by 2002:a17:902:dad0:b0:1a3:dcc1:307d with SMTP id q16-20020a170902dad000b001a3dcc1307dmr23896780plx.23.1682439880274; Tue, 25 Apr 2023 09:24:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682439880; cv=none; d=google.com; s=arc-20160816; b=HaI9qkmvmZ85ijcPU8uJfB6+J+7z5CTzugVI8BDqhQhkevxwvb8eXh3uViqG7pjEip QeQ7lh6cxIN1saEZb4F+tKgV3K3UF6DdPXQv5qwwexGkjMRiQuZgeipGZMQVoXVWFoGN 7rgIu/4loSw8AxuJQLU8wKAP5n9f5F6j1ktLXtgPlHZsmPM8vIeGHNnh8CF3WMPHvJ/V YTyxcri9hJc2oQe459V3nw3OmTgXPY1VeqhX3V98V/aIxlsy61UnffFdIHAxp7Is0lI4 irMaB8zzrAkNvPXcAQALSPzV8BKjpEOF3ymv4bS+hAuXLJJygo06J+5U7QhvD1irTGVg XEvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=518NqRonnFHD2DxxKO+SEaWfT76uscNDaew1RMNKyb8=; b=hTYa3sDoGnvtaKdR7jvq4cCj3JHRi5yqnMnWxSZ41cLEMf3C9cyWujiL+0fEacKAyy fZhtj81ep4vtY7815fQd9EU4PArrmeLEgp7xGNXdA96kx6wvodrcNqb+3egiAO+7SWlM AfoB2mKCxoWuCz8h7T2Ph3IGjs0b3Pb8EOCBfKojG11gUZxCOPI75ipUT2/Ca0ucwiG1 3NzcLikle4Kegtr8n+thDpSxSNs8w0pvazIj79LqdfVc4VFyvtgCb+rQdWuerHk1XVvn rlcxg4QVyobyh5Evhh0NxuKyrr1DhAMjrWS5HD458YrZGBrT29AeVbEeL0qwIxQNrLBl oJ3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c2-20020a17090a108200b0024799a3324dsi12291530pja.162.2023.04.25.09.24.26; Tue, 25 Apr 2023 09:24:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234150AbjDYQVj (ORCPT + 99 others); Tue, 25 Apr 2023 12:21:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233893AbjDYQVh (ORCPT ); Tue, 25 Apr 2023 12:21:37 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C26C92684; Tue, 25 Apr 2023 09:21:35 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E2F24B3; Tue, 25 Apr 2023 09:22:19 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CD31A3F587; Tue, 25 Apr 2023 09:21:31 -0700 (PDT) Message-ID: <45bc13a8-1442-2dd3-b9ea-1ed2f5962bac@arm.com> Date: Tue, 25 Apr 2023 17:21:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-GB To: Nicolas Ferre , Daniel Palmer , Ansuel Smith , Claudiu Beznea , Alexandre Belloni , Santiago Esteban , Cristian Birsan Cc: Rob Herring , Krzysztof Kozlowski , linux-arm-kernel , DTML , Linux Kernel Mailing List , linux-actions@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-omap@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@axis.com, linux-aspeed@lists.ozlabs.org, linux-rpi-kernel@lists.infradead.org, chrome-platform@lists.linux.dev, linux-renesas-soc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, kernel@dh-electronics.com, linux-mediatek@lists.infradead.org, openbmc@lists.ozlabs.org, linux-tegra@vger.kernel.org, linux-oxnas@groups.io, linux-arm-msm@vger.kernel.org, linux-unisoc@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-realtek-soc@lists.infradead.org References: <20220328000915.15041-1-ansuelsmth@gmail.com> <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> From: Robin Murphy In-Reply-To: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, WEIRD_QUOTING autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/03/2022 9:50 am, Nicolas Ferre wrote: > Ansuel, All, > > On 28/03/2022 at 10:55, Daniel Palmer wrote: >> Hi Ansuel >> >> On Mon, 28 Mar 2022 at 09:09, Ansuel Smith wrote: >>> >>> Hi, >>> as the title say, the intention of this ""series"" is to finally >>> categorize >>> the ARM dts directory in subdirectory for each oem. >> >> While I agree with this change and think it's for the good (browsing >> the ARM dts directory at the moment is frustrating..) I think >> buildroot and others need to be told about this as it'll potentially >> break their kernel build scripting for ARM and probably messes up the >> configs they have for existing boards. > > This aspect mustn't be underestimated and I anticipate lots of issues > during a long time on this particular topic of "build systems". > > Another aspect is CI and public or private testing farms we all have > running. Yet another is if this affects what `make dtbs_install` does (I don't know for sure, but I'd be inclined to suspect it might). Some distros use that to deliver the DTBs as part of their kernel package, so if paths suddenly change it could break end users' bootloader setups too. Thanks, Robin. > These aspects always refrained me to change anything in the naming > scheme of our DT files, but if we go in this direction, we must really > be prepared and I'm still not convince it's worth it... > > > If this has to happen, I would also like to queue some file name changes > to do all modifications in one go in order to lower the annoyance level > of those who would need to adapt to those changes. > > BTW, is there a common scheme for dts/dtsi file naming? Is it more > enforced in one way or another for arm64 in a sense that I can take some > norm as an example? > > [..] > > Best regards, >   Nicolas > > >