From: Thomas Gleixner <firstname.lastname@example.org> To: "Pali Rohár" <email@example.com>, "Marc Zyngier" <firstname.lastname@example.org> Cc: "Rob Herring" <email@example.com>, "Bjorn Helgaas" <firstname.lastname@example.org>, "Andrew Lunn" <email@example.com>, "Gregory Clement" <firstname.lastname@example.org>, "Sebastian Hesselbarth" <email@example.com>, "Thomas Petazzoni" <firstname.lastname@example.org>, "Lorenzo Pieralisi" <email@example.com>, "Krzysztof Wilczyński" <firstname.lastname@example.org>, "Marek Behún" <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, "Greg Kroah-Hartman" <firstname.lastname@example.org> Subject: Re: [PATCH 2/6] irqchip/armada-370-xp: Implement SoC Error interrupts Date: Mon, 09 May 2022 10:51:57 +0200 [thread overview] Message-ID: <87sfpjytoy.ffs@tglx> (raw) In-Reply-To: <20220506185546.n5rl3chyyauy4bjt@pali> Pali, On Fri, May 06 2022 at 20:55, Pali Rohár wrote: > On Friday 06 May 2022 19:47:25 Marc Zyngier wrote: >> > I'm not rewriting driver or doing big refactor of it, as this is not in >> > the scope of the PCIe AER interrupt support. >> >> Fair enough. By the same logic, I'm not taking any change to the >> driver until it is put in a better shape. Your call. > > If you are maintainer of this code then it is expected from _you_ to > move the current code into _better shape_ as you wrote and expect. And > then show us exactly, how new changes in this driver should look like, > in examples. this is not how kernel development works. Maintainers are not the servants who mop up the mess which random people dump into the tree. They are gatekeepers and one of their duties is to prevent that mess is created or existing mess is proliferated. You are asking the maintainer to take your changes, deal with the fallout and maintain them for a long time free of charge. So it's a very reasonable request from a maintainer to ask for refactoring of existing code before adding new functionality to it. With such a request the refactoring becomes scope of your work, whether you and your manager like it or not. If you don't want to do that extra work, then don't expect maintainers to care about your fancy new features. Marc gave you very reasonable and consice directions how the code should be reworked. He spent a lot of time explaining it to you. Again, free of charge. Now you expect him to do your homework free of charge, so you can get your feature merged? Nice try. Thanks, Thomas
next prev parent reply other threads:[~2022-05-09 9:27 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-06 13:40 [PATCH 0/6] PCI: mvebu: Add support for PME and AER interrupts Pali Rohár 2022-05-06 13:40 ` [PATCH 1/6] dt-bindings: irqchip: armada-370-xp: Update information about MPIC SoC Error Pali Rohár 2022-05-17 0:18 ` Rob Herring 2022-05-06 13:40 ` [PATCH 2/6] irqchip/armada-370-xp: Implement SoC Error interrupts Pali Rohár 2022-05-06 18:19 ` Marc Zyngier 2022-05-06 18:30 ` Pali Rohár 2022-05-06 18:47 ` Marc Zyngier 2022-05-06 18:55 ` Pali Rohár 2022-05-07 9:01 ` Marc Zyngier 2022-05-07 9:20 ` Pali Rohár 2022-05-07 9:42 ` Marc Zyngier 2022-05-07 11:15 ` Pali Rohár 2022-05-09 23:12 ` Rob Herring 2022-05-09 8:51 ` Thomas Gleixner [this message] 2022-05-06 13:40 ` [PATCH 3/6] ARM: dts: armada-38x.dtsi: Add node for MPIC SoC Error IRQ controller Pali Rohár 2022-05-06 13:40 ` [PATCH 4/6] dt-bindings: PCI: mvebu: Update information about summary interrupt Pali Rohár 2022-05-06 13:40 ` [PATCH 5/6] PCI: mvebu: Implement support for interrupts on emulated bridge Pali Rohár 2022-05-06 13:40 ` [PATCH 6/6] ARM: dts: armada-385.dtsi: Add definitions for PCIe summary interrupts Pali Rohár 2022-05-06 14:22 ` [PATCH 0/6] PCI: mvebu: Add support for PME and AER interrupts Pali Rohár
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=87sfpjytoy.ffs@tglx \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 2/6] irqchip/armada-370-xp: Implement SoC Error interrupts' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).