[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f5e752abc5929cfc8fffd55f5991ab48f141c200.camel@svanheule.net>
Date: Wed, 29 Dec 2021 21:03:15 +0100
From: Sander Vanheule <sander@...nheule.net>
To: Birger Koblitz <mail@...ger-koblitz.de>
Cc: linux-kernel@...r.kernel.org, bert@...t.com, john@...ozen.org,
tglx@...utronix.de, maz@...nel.org, robh+dt@...nel.org,
devicetree@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/5] Rework realtek-rtl IRQ driver
Hi Birger,
On Tue, 2021-12-28 at 09:09 +0100, Birger Koblitz wrote:
> Hi Sander,
> > I haven't tested this with VSMP, because it is out of scope for this series. For the
> > binding, I expect that would only require N register ranges instead of one; one per
> > CPU. I think the driver should then be able to perform the IRQ balancing based on that
> > information alone, given that the parent IRQs are available at each CPU.
>
> whether this is out of the scope of this series is not the point. In my experience you
> only see issues with locking and race conditions with the IRQ driver if you test with
> VSMP enabled,
> because only with VSMP you can be in the IRQ code multiple times at the same time. Since
> you want to change routing logic and hierarchies I would believe it to be a very good
> idea
> to test that. The present code passes that test.
Implementing CPU affinity is a separate issue for after these patches IMHO. The current
problems have to be fixed anyway. Otherwise you're just compounding (potential) issues,
only making further development harder.
FWIW, the driver with these (reworked) patches runs fine on my RTL839x (Zyxel GS1900-48)
with SMP enabled. That's without implementing CPU affinity support on this driver, so all
SoC interrupts just go to CPU0. If any issues with lock-ups show up later, we can fix them
when they appear.
Best,
Sander
Powered by blists - more mailing lists