[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8cdac20c-e860-4157-95c0-6e8250e50af5@gmx.net>
Date: Sun, 17 Dec 2023 20:17:56 +0100
From: Stefan Wahren <wahrenst@....net>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 02/12 net-next] qca_spi: Improve SPI IRQ handling
Hi Andrew,
Am 17.12.23 um 19:14 schrieb Andrew Lunn:
> On Thu, Dec 14, 2023 at 04:09:34PM +0100, Stefan Wahren wrote:
>> The functions qcaspi_netdev_open/close are responsible of request &
>> free of the SPI interrupt, which wasn't the best choice because
>> allocation problems are discovered not during probe. So let us split
>> IRQ allocation & enabling, so we can take advantage of a device
>> managed IRQ.
> Could you replace the kernel thread with a threaded interrupt handler?
the kernel thread is responsible for receiving, transmitting and reset
handling (there is no GPIO reset in this driver) which must be
synchronized along the same SPI interface. The interrupt just signalize
a chip reset or a received packet is available.
Could you please elaborate this request more in detail:
What is the problem with the kernel thread?
Why should i use the threaded interrupt as a replacement instead of e.g.
workqueue?
Please don't get me wrong, but i need to convince my employer for such a
big rewrite.
Regards
>
> Andrew
Powered by blists - more mailing lists