Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Pali =?utf-8?Q?Roh=C3=A1r?= <pali@kernel.org>,
        Marc Zyngier <maz@kernel.org>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Gregory Clement <gregory.clement@bootlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>,
        Marek =?utf-8?Q?Beh=C3=BAn?= <kabel@kernel.org>,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 2/6] irqchip/armada-370-xp: Implement SoC Error interrupts
In-Reply-To: <20220506185546.n5rl3chyyauy4bjt@pali>
References: <20220506134029.21470-1-pali@kernel.org>
 <20220506134029.21470-3-pali@kernel.org> <87mtfu7ccd.wl-maz@kernel.org>
 <20220506183051.wimo7p4nuqfnl2aj@pali> <8735hmijlu.wl-maz@kernel.org>
 <20220506185546.n5rl3chyyauy4bjt@pali>
Date:   Mon, 09 May 2022 10:51:57 +0200
Message-ID: <87sfpjytoy.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Pali,

On Fri, May 06 2022 at 20:55, Pali Roh=C3=A1r 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