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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 28 Oct 2021 17:25:14 +0100,
Marek Behún <kabel@xxxxxxxxxx> wrote:
> 
> On Thu, 28 Oct 2021 17:51:50 +0200
> Marek Behún <kabel@xxxxxxxxxx> 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.

	M.

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux