LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Li Yang <leoyang.li@nxp.com>, Scott Wood <oss@buserror.net>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms
Date: Tue, 21 Feb 2023 23:00:44 +0100	[thread overview]
Message-ID: <20230221220044.6j5fhxnook7yl6v3@pali> (raw)
In-Reply-To: <Y/U5Ova9P78omJ66@windriver.com>

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)

  reply	other threads:[~2023-02-21 22:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 19:46 [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms Paul Gortmaker
2023-02-21 19:46 ` [PATCH 1/4] powerpc: drop MPC8540_ADS and MPC8560_ADS platform support Paul Gortmaker
2023-02-21 19:46 ` [PATCH 2/4] powerpc: drop MPC85xx_CDS " Paul Gortmaker
2023-02-21 19:46 ` [PATCH 3/4] powerpc: drop MPC8568_MDS / P1021_MDS " Paul Gortmaker
2023-02-21 19:46 ` [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments Paul Gortmaker
2023-02-21 20:03   ` Pali Rohár
2023-02-21 21:29     ` Paul Gortmaker
2023-02-21 21:49       ` Pali Rohár
2023-03-02 23:30         ` Crystal Wood
2023-03-03  0:25           ` Paul Gortmaker
2023-02-21 20:13 ` [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms Pali Rohár
2023-02-21 21:35   ` Paul Gortmaker
2023-02-21 22:00     ` Pali Rohár [this message]
2023-02-27 21:16 ` Li Yang
2023-04-14  2:13   ` Michael Ellerman
2023-04-14 23:29     ` Leo Li
2023-04-17 15:00       ` Paul Gortmaker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230221220044.6j5fhxnook7yl6v3@pali \
    --to=pali@kernel.org \
    --cc=claudiu.manoil@nxp.com \
    --cc=leoyang.li@nxp.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=oss@buserror.net \
    --cc=paul.gortmaker@windriver.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox