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 D4FADC433F5 for ; Tue, 29 Mar 2022 07:53:48 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SVZa+crr2bKiJuRBQhldpoZjKh3IIY1l7ZtxURr6qSw=; b=yH9BlztzmZ0NuC SJeohcAn2g2cPd2/T0Em2j5qyo468M3LHq94c15C0+bwqYUbjV3UdBtml19Iq2jL/OveToBMmpQnh +sn+EW8vMSk5XLu90QQ5JRia+FZv2K+gSDEI9uGg0mhnf4B3GbBQ0Dmpluz/kBYhQw8JvFdFFoIky lOjFhUg3qpyxLiQqFVKUxcCWy8mxQA56UhIb+oHuKXv2pkAnwVGZoUesFuq8RT6OJo/t90xI9WqMZ 85us1KWLUWVJBcHeVu2HZycwerTaK4AmyUQlSFecIxUxlRF3J078ZQcTlrePRVovDG/ngd79Ym8YB ZVaikCR9hNBDA/jc0w1w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ6fh-00BOGf-Op; Tue, 29 Mar 2022 07:53:45 +0000 Received: from muru.com ([72.249.23.125]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nZ6fT-00BOCz-3n; Tue, 29 Mar 2022 07:53:32 +0000 Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 727F580F9; Tue, 29 Mar 2022 07:51:24 +0000 (UTC) Date: Tue, 29 Mar 2022 10:53:27 +0300 From: Tony Lindgren To: Daniel Palmer Cc: Ansuel Smith , 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 Subject: Re: [RFC PATCH 0/1] Categorize ARM dts directory Message-ID: References: <20220328000915.15041-1-ansuelsmth@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220329_005331_237669_383133D7 X-CRM114-Status: GOOD ( 18.53 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Hi, * Daniel Palmer [220328 08:53]: > 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. Yeah.. And ideally this would be done in smaller steps as these will conflict with all the other pending patches. For example, I have a pile of pending omap clock clean-up dts patches posted and tested waiting for v5.19-rc1 to apply. I'd rather not start redoing or fixing up the patches with sed :) What I'd like to have see is that at some point when suitable we move one machine at a time with a script if possible.. Maybe the dtb files generated would need to remain in the current directory until all of the machine dts files are moved? That should help with the build scripting too probably :) In general I like the idea though and I think we should do it. Regards, Tony _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip