Re: [PATCH 10/14] PCI: aardvark: Enable MSI-X support

["Marek Behún" <kabel@kernel.org>]

On Thu, 28 Oct 2021 18:47:18 +0100
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:

> On Thu, Oct 28, 2021 at 06:00:47PM +0100, Marc Zyngier wrote:
> > On Thu, 28 Oct 2021 17:25:14 +0100,
> > Marek Behún <kabel@kernel.org> wrote:  
> > > 
> > > On Thu, 28 Oct 2021 17:51:50 +0200
> > > Marek Behún <kabel@kernel.org> wrote:
> > >   
> > > > Marc, we have ~70 patches ready for the aardvark controller driver.
> > > > 
> > > > It is patch 53 [1] that converts the old irq_find_mapping() +
> > > > generic_handle_irq() API to the new API, so it isn't that Pali did
> > > > not address your comments, it is that, due to convenience, he addressed
> > > > them in a later patch.
> > > > 
> > > > The last time Pali sent a larger number of paches (in a previous
> > > > version, which was 42 patches [1]), it was requested that we split the
> > > > series into smaller sets, so that it is easier to merge.
> > > > 
> > > > Since then some more changes accumulated, resulting in the current ~70
> > > > patches, which I have been sending in smaller batches.
> > > > 
> > > > I could rebase the entire thing so that the patch changing the usage of
> > > > the old irq_find_mapping() + generic_handle_irq() API is first. But
> > > > that would require rebasing and testing all the patches one by one,
> > > > since the patches in-between touch everything almost everything else.
> > > > 
> > > > If it is really that problematic to review the changes while they use
> > > > the old API, please let me know and I will rebase it. But if you could
> > > > find it in yourself to review the patches with old API usage, it would
> > > > really save a lot of time and the result will be the same, to your
> > > > satisfaction.  
> > > 
> > > Lorenzo, Marc, Bjorn,
> > > 
> > > I have one more question.
> > > 
> > > Pali prepared the ~70 patches so that fixes come first, and
> > > new features / changes to new API later.
> > > 
> > > He did it in this way so that the patches could be then conventiently
> > > backported to stable versions - were we to first change the API usage
> > > to the new API, and then fix the ~20 IRQ related things, we would
> > > afterwards have to backport the fixes by rewriting them one by one.
> > > 
> > > Is this really how we should do this? Should we ignore stable while
> > > developing for master, regardless of how much other work would need to
> > > be spent by backporting to master, even if it could be much simpler by
> > > applying the patches in master in another order?  
> > 
> > I already replied to that in August. Upstream is the primary
> > development target. If you want to backport patches, do them and make
> > the changes required so that they are correct for whatever kernel you
> > target. Stable doesn't matter to upstream at all.  
> 
> +1
> 
> Please don't write patch series with stable backports in mind, don't.
> 
> Let's focus on mailine with one series at a time, I understand it is
> hard but that's the only way we can work and I can keep track of what
> you are doing, if we keep splitting patch series I can't track reviews
> and then we end up in this situation. I asked if you received Marc's
> feedback exactly because I can't track the original discussion and if I
> merged the series (the MSI bits) I would have ignored what Marc
> requested you to do and that's not OK.
> 
> So, given the timing, I will try to merge patches [1-3] and [11-14]
> if I can rebase the series cleanly; maybe I can include patch 9 if
> it does not depend on previous patches.

Very well. Ignore patch 9, since it touches IRQ. In the next batch I
shall send IRQ changes, with the first or second patch converting to
this new API.

Marek