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@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. +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. Thanks, Lorenzo
