Re: [PATCH net-next] net: enc28j60: Use threaded interrupt instead of workqueue

[Leon Romanovsky <leon@kernel.org>]

On Tue, May 09, 2023 at 03:36:20PM +0200, Lukas Wunner wrote:
> On Tue, May 09, 2023 at 11:06:27AM +0300, Leon Romanovsky wrote:
> > On Tue, May 09, 2023 at 06:28:56AM +0200, Lukas Wunner wrote:
> > > From: Philipp Rosenberger <p.rosenberger@kunbus.com>
> > > 
> > > The Microchip ENC28J60 SPI Ethernet driver schedules a work item from
> > > the interrupt handler because accesses to the SPI bus may sleep.
> > > 
> > > On PREEMPT_RT (which forces interrupt handling into threads) this
> > > old-fashioned approach unnecessarily increases latency because an
> > > interrupt results in first waking the interrupt thread, then scheduling
> > > the work item.  So, a double indirection to handle an interrupt.
> > > 
> > > Avoid by converting the driver to modern threaded interrupt handling.
> > > 
> > > Signed-off-by: Philipp Rosenberger <p.rosenberger@kunbus.com>
> > > Signed-off-by: Zhi Han <hanzhi09@gmail.com>
> > > [lukas: rewrite commit message, linewrap request_threaded_irq() call]
> > 
> > This is part of changelog which doesn't belong to commit message. The
> > examples which you can find in git log, for such format like you used,
> > are usually reserved to maintainers when they apply the patch.
> 
> Is that a new rule?

No, this rule always existed, just some of the maintainers didn't care
about it.

> 
> Honestly I think it's important to mention changes applied to
> someone else's patch, if only to let it be known who's to blame
> for any mistakes.

Right, this is why maintainers use this notation when they apply
patches. In your case, you are submitter, patch is not applied yet
and all changes can be easily seen through lore web interface.

> 
> I'm seeing plenty of recent precedent in the git history where
> non-committers fixed up patches and made their changes known in
> this way, e.g.:

It doesn't make it correct.
Documentation/maintainer/modifying-patches.rst

Thanks