From: Nicolai Buchwitz <nb@tipi-net.de>
To: Marek Vasut <marex@nabladev.com>
Cc: netdev@vger.kernel.org, stable@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Ronald Wahl <ronald.wahl@raritan.com>,
Yicong Hui <yiconghui@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
Date: Fri, 10 Apr 2026 09:29:39 +0200 [thread overview]
Message-ID: <18b34c8823dd2bcf06c2aff29404c25d@tipi-net.de> (raw)
In-Reply-To: <1665242a-2298-4e76-9618-effdb88c2ad4@nabladev.com>
On 9.4.2026 17:26, Marek Vasut wrote:
> On 4/9/26 8:52 AM, Nicolai Buchwitz wrote:
>
> Hello Nicolai,
>
>>> @@ -408,7 +426,9 @@ static int ks8851_net_open(struct net_device
>>> *dev)
>>> unsigned long flags;
>>> int ret;
>>>
>>> - ret = request_threaded_irq(dev->irq, NULL, ks8851_irq,
>>> + ret = request_threaded_irq(dev->irq, NULL,
>>> + ks->no_bh_in_irq_handler ?
>>> + ks8851_irq_nobh : ks8851_irq,
>>
>> This works, but wouldn't it be simpler to put the BH disable
>> into the PAR lock/unlock directly?
>>
>> static void ks8851_lock_par(...)
>> {
>> local_bh_disable();
>> spin_lock_irqsave(&ksp->lock, *flags);
>> }
>>
>> static void ks8851_unlock_par(...)
>> {
>> spin_unlock_irqrestore(&ksp->lock, *flags);
>> local_bh_enable();
>> }
>>
>> No flag, no wrapper, no conditional in request_threaded_irq.
>> And it protects all PAR lock/unlock callsites, not just the
>> IRQ handler.
> That is exactly why I wrapped the IRQ handler, because the BH should be
> disabled ONLY around the IRQ handler, not around the other call sites.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
next prev parent reply other threads:[~2026-04-10 7:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 16:24 [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler Marek Vasut
2026-04-09 6:52 ` Nicolai Buchwitz
2026-04-09 15:26 ` Marek Vasut
2026-04-10 7:29 ` Nicolai Buchwitz [this message]
2026-04-12 16:01 ` Jakub Kicinski
2026-04-12 16:27 ` Marek Vasut
2026-04-12 17:51 ` Jakub Kicinski
2026-04-13 12:57 ` Sebastian Andrzej Siewior
2026-04-13 15:31 ` Marek Vasut
2026-04-13 16:03 ` Sebastian Andrzej Siewior
2026-04-14 8:55 ` Sebastian Andrzej Siewior
2026-04-14 10:26 ` Marek Vasut
2026-04-13 15:44 ` Jakub Kicinski
2026-04-13 16:10 ` Sebastian Andrzej Siewior
2026-04-14 10:07 ` Marek Vasut
2026-04-14 10:48 ` Sebastian Andrzej Siewior
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=18b34c8823dd2bcf06c2aff29404c25d@tipi-net.de \
--to=nb@tipi-net.de \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@nabladev.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ronald.wahl@raritan.com \
--cc=stable@vger.kernel.org \
--cc=yiconghui@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.