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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 7AA0CC636D7 for ; Tue, 21 Feb 2023 22:01:44 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PLtY25jJPz3cFn for ; Wed, 22 Feb 2023 09:01:42 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=XkUQWZr2; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=pali@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=XkUQWZr2; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4PLtX23t5Sz3bgx for ; Wed, 22 Feb 2023 09:00:50 +1100 (AEDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AA630611E2; Tue, 21 Feb 2023 22:00:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1441C433D2; Tue, 21 Feb 2023 22:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677016847; bh=j0zrKP/GGHhSUG30UAklPpysturO9uPV/EYPEoyyxIU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XkUQWZr27z4VKyDNMHOLD76wIWkLB0BCviBL8P+7hqxuclTgA1oh6hpIsGcZ0kBCI SiOZXpwlS14UpWi0AKTVCKx+4cPgQAI/feLuBQmJ3T6Cm8gNIzeGyjy+K90l8rgW98 SjEgKOO1XHXWBIwz+pgv4ZgMJ+ULaTkA9xrp918+BToTxwlNCXHglX/lVMSblX2Zmv YNe37ypD+bSrf9PrxgMQeXbozHJrVqxNdN+EgtbyFrjPIlHl+mJRXkiM5HRbNctXGl DOZMn92DKAQJ4VaXGJ6UcKiZ5Mud3I+aj9KbY6EJjoytnea+Gmhrqz0mm9C4VciAg9 xdSF7jWBBJgIg== Received: by pali.im (Postfix) id 57CB6708; Tue, 21 Feb 2023 23:00:44 +0100 (CET) Date: Tue, 21 Feb 2023 23:00:44 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Paul Gortmaker Subject: Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms Message-ID: <20230221220044.6j5fhxnook7yl6v3@pali> References: <20230221194637.28436-1-paul.gortmaker@windriver.com> <20230221201311.sadp3sq7xr25hcuu@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Li Yang , Scott Wood , Claudiu Manoil , Paul Mackerras , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tuesday 21 February 2023 16:35:54 Paul Gortmaker wrote: > [Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms] On 21/02/2023 (Tue 21:13) Pali Roh??r wrote: > > > Hello! I would like to let you know that I have there patch series which > > creates one generic machine descriptor for all P2 boards: > > https://lore.kernel.org/linuxppc-dev/20230218111405.27688-1-pali@kernel.org/ > > > > Basically it allows any P2 board to boot one universal kernel binary > > just with correct DTS file. After P2 is merged I was thinking about > > looking at P1 boards too. > > > > So I would suggest to do some "big" removal of older code after this is > > merged, so I do not have to rebase again my patch series which is > > basically cleanup and make maintenance easier. > > Thanks for the update -- I don't want to make extra work for anyone. > > If I drop the MPC8568/P1 removal for now, then would you agree that your work > and the remaining changes - this ADS/CDS removal can continue in parallel? I hope that Christophe review my patches soon. I'm looking again at my and your changes and seems that there should not be conflicts because my patches touches only mpc85xx_ds.c+mpc85xx_rdb.c and your changes touches remaining mpc85xx_*.c board files. About P1 I have not decided if I do some code work in this area. I wanted to look at it (and if it is big maybe I just drop my idea). So I think both your and my patch series could continue in parallel (in case they are not going to be bigger). > Thanks, > Paul. > -- > > > > > I understand that removing old machine descriptions with board code for > > old boards which nobody use and nobody wants to maintain is logical > > step. > > > > But if something like generic machine descriptor for P1 happens too > > (like I did for P2 in above patch series), it would mean that the only > > board specific information would be stored in DTS files. > > And does it make sense to remove just old DTS files? Are there any > > maintenance with them? (Do not take it wrong, just I'm asking)