From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DF6F20E5; Tue, 29 Mar 2022 08:51:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1648543916; x=1680079916; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=0r3zs2np5g1OGyfR5AfBJmzryAoR1xJqsqcoDejQqWU=; b=JF4ojGmb2yCqpVpeCGWTr1KAaJH1p+op+RfU2Cy5spHuPTuzxH5fT6XO uX4my4AmAvxU1NnQgj1gnLLCvB5GApvDq/ZIefA+Fj2nabXYsgdFCTdNh KIiZuakxKSWUbw59OtVsu66KLGifDxNLiOUOfsjhp8FSKI7j2yvO8sj3L Be7099C0S1QS6sRyn1MuET9sFsteKnNAI+fFLYa6rTUl+Fun8esKSeU84 bl3fFECuVi2YFVU0Up7Dk4VoEaJs61oMc1tqFaPDdsL6SoBQjtAfPtYVi inSH2nN+Ve5dEljYugV7bakO+la5NMYS2RKOAEiEMZkXqF6ejnz/b6ru1 Q==; X-IronPort-AV: E=Sophos;i="5.90,219,1643698800"; d="scan'208";a="158497460" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Mar 2022 01:50:48 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 29 Mar 2022 01:50:48 -0700 Received: from [10.159.245.112] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Tue, 29 Mar 2022 01:50:41 -0700 Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Date: Tue, 29 Mar 2022 10:50:38 +0200 Precedence: bulk X-Mailing-List: chrome-platform@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-US To: 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 , , , , , , , , , , , , , , , , , , , , References: <20220328000915.15041-1-ansuelsmth@gmail.com> From: Nicolas Ferre Organization: microchip In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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. 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 -- Nicolas Ferre 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2ADE2C4332F for ; Tue, 29 Mar 2022 08:51:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lOhmjiWVkx5O8nKrHkU7klcnBySIFrqbfSRetXsIm6E=; b=hw6B3CzsLEDBe0 x++UgOfQ4E+rNHVawNAkWL/hYGWMig/UHC0EcOQR/vJF6Uv1rbAa5WHQxRIhDq03tyaOPdRDqHeTS YXo25Wri7hUsM70r/qa7PCOImCrIg04LzVNl25j63rWZTBtr9cD6CtIQehpQcb3f+s9DetmCpN9C7 NqIFXdJjigQGwZEbRtXb1fgUcozUa4iWstyyR6qD6LkC/DAmCvTUnEQEeum23YyvEgLt++gBrNd2D c7aQOe0m0PJhLPeuOz78PJtyQxRwV0KBuP2AE5q9nwnkk9HinCVwlt+xjp1wlDzEW928QfBCKlbfC KacG3X1ZwiIAyukb5rxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Z3-00BVIU-5q; Tue, 29 Mar 2022 08:50:57 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Yx-00BVH1-Se; Tue, 29 Mar 2022 08:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1648543851; x=1680079851; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=0r3zs2np5g1OGyfR5AfBJmzryAoR1xJqsqcoDejQqWU=; b=SvzazobpV11jWeMgpXo0FTvE1SLSgCyZ7Xqqf+G+mtJGMfNJ9dbOCrDf ysi5EidKWkWJ49RAyHugcujFV5Kw0oT1phK7DlUFPa6sZN1D1b/yMAXmv RCdj/QsyqhI3Z1SjDcDYeAcyh/VPEi7+sI5OLoYwx9CjtHPiYDaJevD76 8I6jXHHTjFr79/zR8y4Bgh1Gy35vFCZqn2MULJmTFkyb95PUicosRdfrd ZDbhw2po6iiow2+V+HMacAd2XS96BryxDwBl6ib89n3nhoZYszcVOAd31 VA5WMVXwoTHyfGGelRpyFs3vNbtaDve3Zad+K6r7cbpt8O6NzEkpqUN+Y A==; X-IronPort-AV: E=Sophos;i="5.90,219,1643698800"; d="scan'208";a="158497460" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Mar 2022 01:50:48 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 29 Mar 2022 01:50:48 -0700 Received: from [10.159.245.112] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Tue, 29 Mar 2022 01:50:41 -0700 Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Date: Tue, 29 Mar 2022 10:50:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-US To: 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 , , , , , , , , , , , , , , , , , , , , References: <20220328000915.15041-1-ansuelsmth@gmail.com> From: Nicolas Ferre Organization: microchip In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220329_015052_008233_4845F7E3 X-CRM114-Status: GOOD ( 16.75 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org 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. 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 -- Nicolas Ferre _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Ferre Date: Tue, 29 Mar 2022 10:50:38 +0200 Subject: [RFC PATCH 0/1] Categorize ARM dts directory In-Reply-To: References: <20220328000915.15041-1-ansuelsmth@gmail.com> Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. 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 -- Nicolas Ferre 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D7D3BC433F5 for ; Tue, 29 Mar 2022 08:51:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lvruhvfSfb6aAUvRXjHuZ4dOBn9FjRgTc3Be3wlyiPg=; b=ke8vtxGh6wE0N6 RZEWM8bne7UAkvZcQTk+lk3rxpk6aJPQ31o+qHgVd9tpAF3pQ5iggcGhQEvfNHpqdFHvKNmS7Gp0i EL7xun+gKRdDDk1H3QepznDbDzyc2obGjrQm2efDz+ODgaDVlPgxLhajPiRR+9CaBhCwCm9WFxryi YaPHwBHRtuLbcpayN838z5vARQlcYKKHT6kDdQlRFi927X0jSan8eMldjJPOjduth4iMp0Ea1lRAC aMmzh564DxduXWEHneCaxxdJsvFJ44IQGymTxPINydU25kTu1JyBHBW3kV+fbtTqhV0uwsC7cpmpx /U0Mdr+2ChjaSUcMcqZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Z2-00BVIM-BZ; Tue, 29 Mar 2022 08:50:56 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Yx-00BVH1-Se; Tue, 29 Mar 2022 08:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1648543851; x=1680079851; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=0r3zs2np5g1OGyfR5AfBJmzryAoR1xJqsqcoDejQqWU=; b=SvzazobpV11jWeMgpXo0FTvE1SLSgCyZ7Xqqf+G+mtJGMfNJ9dbOCrDf ysi5EidKWkWJ49RAyHugcujFV5Kw0oT1phK7DlUFPa6sZN1D1b/yMAXmv RCdj/QsyqhI3Z1SjDcDYeAcyh/VPEi7+sI5OLoYwx9CjtHPiYDaJevD76 8I6jXHHTjFr79/zR8y4Bgh1Gy35vFCZqn2MULJmTFkyb95PUicosRdfrd ZDbhw2po6iiow2+V+HMacAd2XS96BryxDwBl6ib89n3nhoZYszcVOAd31 VA5WMVXwoTHyfGGelRpyFs3vNbtaDve3Zad+K6r7cbpt8O6NzEkpqUN+Y A==; X-IronPort-AV: E=Sophos;i="5.90,219,1643698800"; d="scan'208";a="158497460" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Mar 2022 01:50:48 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 29 Mar 2022 01:50:48 -0700 Received: from [10.159.245.112] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Tue, 29 Mar 2022 01:50:41 -0700 Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Date: Tue, 29 Mar 2022 10:50:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-US To: 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 , , , , , , , , , , , , , , , , , , , , References: <20220328000915.15041-1-ansuelsmth@gmail.com> From: Nicolas Ferre Organization: microchip In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220329_015052_008233_4845F7E3 X-CRM114-Status: GOOD ( 16.75 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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. 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 -- Nicolas Ferre _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 02EE0C433EF for ; Tue, 29 Mar 2022 08:51:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=RpenWEijPBeCfFm6lCjG5RaYPigIVmeE7gfQS/Lpnu0=; b=q7BMgIxsypciFt QAm2s7nTUwIl45j22hnfcelvytbWSeKPTHdypRvU6gxyeZmuD9kkc5xN3yBgux4SZYdkgnvPr3OS3 x8YQVFHhHaXwatFGf5RuInVNC2xl0vYPGIyHgIcOHA8Zih6uWDYFegjr6fiih4bhST4zDG19f4zMR 5V/1zxR10SleWiOMx89Nfp1U6DFDyzOZgmpP9l6w3isguRnn35uB5zmcXWkxFeUt6PFUABnemW9sZ ol3JhVorayaBM1Aa5C3ZCyfDLx7u9QMyt4rz5YZ1s4rCW11NP92Oy1A061yGZ0Cvl2BBelcH80r86 qkW1GDfmNhMfIpzYlFYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7ZF-00BVQK-Ub; Tue, 29 Mar 2022 08:51:09 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Yx-00BVH1-Se; Tue, 29 Mar 2022 08:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1648543851; x=1680079851; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=0r3zs2np5g1OGyfR5AfBJmzryAoR1xJqsqcoDejQqWU=; b=SvzazobpV11jWeMgpXo0FTvE1SLSgCyZ7Xqqf+G+mtJGMfNJ9dbOCrDf ysi5EidKWkWJ49RAyHugcujFV5Kw0oT1phK7DlUFPa6sZN1D1b/yMAXmv RCdj/QsyqhI3Z1SjDcDYeAcyh/VPEi7+sI5OLoYwx9CjtHPiYDaJevD76 8I6jXHHTjFr79/zR8y4Bgh1Gy35vFCZqn2MULJmTFkyb95PUicosRdfrd ZDbhw2po6iiow2+V+HMacAd2XS96BryxDwBl6ib89n3nhoZYszcVOAd31 VA5WMVXwoTHyfGGelRpyFs3vNbtaDve3Zad+K6r7cbpt8O6NzEkpqUN+Y A==; X-IronPort-AV: E=Sophos;i="5.90,219,1643698800"; d="scan'208";a="158497460" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Mar 2022 01:50:48 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 29 Mar 2022 01:50:48 -0700 Received: from [10.159.245.112] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Tue, 29 Mar 2022 01:50:41 -0700 Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Date: Tue, 29 Mar 2022 10:50:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-US To: 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 , , , , , , , , , , , , , , , , , , , , References: <20220328000915.15041-1-ansuelsmth@gmail.com> From: Nicolas Ferre Organization: microchip In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220329_015052_008233_4845F7E3 X-CRM114-Status: GOOD ( 16.75 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org 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. 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 -- Nicolas Ferre _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38A0DC433F5 for ; Tue, 29 Mar 2022 08:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cF8X671xGgL8U2vlje95faiauM/b4zfYlFKhP7xNepI=; b=fdtzfDAJYb+0NR +JuvHKc4NUgN9krRBFRaivFgnHmcGL5xcZ24Ch0TLWrePtLZw+HcR1OWNeYoTgfx6lP8Cs2Swm8Mz f5hy537rdMqC0gStpLrhvHBUcDk5zikff88vaiPcLJnmUGCbpybmLtS3YWihroPue8KVRSvGt+fm0 eHNtDZHB976+7rUg53SdP1MO9x9Cx1T7e/v7gyMaUW32a/h0Y5J19HCZIPi6BTjGANBUlcQIsChyx 65rEbbayU6eoqh1pCEM1CUSblBQBk//CD5GBwbVtAw+O6WB7DQC623uPY0iMqUMC18AT2wRkgPnTC i9p9W73bc42lev/riFpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Z5-00BVJS-AJ; Tue, 29 Mar 2022 08:50:59 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ7Yx-00BVH1-Se; Tue, 29 Mar 2022 08:50:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1648543851; x=1680079851; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=0r3zs2np5g1OGyfR5AfBJmzryAoR1xJqsqcoDejQqWU=; b=SvzazobpV11jWeMgpXo0FTvE1SLSgCyZ7Xqqf+G+mtJGMfNJ9dbOCrDf ysi5EidKWkWJ49RAyHugcujFV5Kw0oT1phK7DlUFPa6sZN1D1b/yMAXmv RCdj/QsyqhI3Z1SjDcDYeAcyh/VPEi7+sI5OLoYwx9CjtHPiYDaJevD76 8I6jXHHTjFr79/zR8y4Bgh1Gy35vFCZqn2MULJmTFkyb95PUicosRdfrd ZDbhw2po6iiow2+V+HMacAd2XS96BryxDwBl6ib89n3nhoZYszcVOAd31 VA5WMVXwoTHyfGGelRpyFs3vNbtaDve3Zad+K6r7cbpt8O6NzEkpqUN+Y A==; X-IronPort-AV: E=Sophos;i="5.90,219,1643698800"; d="scan'208";a="158497460" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 29 Mar 2022 01:50:48 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 29 Mar 2022 01:50:48 -0700 Received: from [10.159.245.112] (10.10.115.15) by chn-vm-ex02.mchp-main.com (10.10.85.144) with Microsoft SMTP Server id 15.1.2375.17 via Frontend Transport; Tue, 29 Mar 2022 01:50:41 -0700 Message-ID: <4ff4f171-c5f8-87af-aad1-5e7686292288@microchip.com> Date: Tue, 29 Mar 2022 10:50:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Content-Language: en-US To: 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 , , , , , , , , , , , , , , , , , , , , References: <20220328000915.15041-1-ansuelsmth@gmail.com> From: Nicolas Ferre Organization: microchip In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220329_015052_008233_4845F7E3 X-CRM114-Status: GOOD ( 16.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. 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 -- Nicolas Ferre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel