Re: [PATCH v2 0/4] cxl/events: Robustify event interrupt handling

[Davidlohr Bueso <dave@stgolabs.net>]

On Wed, 02 Sep 2026, Anisa Su wrote:

>On Mon, Aug 31, 2026 at 05:26:53PM -0700, Anisa Su wrote:
>> Based on the 7.2 tag.
>>
>> This patchset bundles various fixes along the event interrupt path.
>> The previous revision was a single patch, but Sashiko reported several
>> related pre-existing errors so I thought I may as well pick them all up into
>> one series.
>>
>> Link to v1:
>> https://lore.kernel.org/linux-cxl/cover.1787768932.git.anisa.su@samsung.com/T/#m393e57d7f7f3916e8f2826a006ef0bc4dfd3606a
>>
>Had a chat with Dave and he mentioned we only need to deal with device quirks
>when they show up. So I plan to drop patches 2-4, since they are just Sashiko
>reports and not observed on hardware.
>
>For patch 1, there are a few considerations, so if any maintainers could have a quick
>glance at the thread?
>
>1. I did observe the bug on hardware, but it's a sample device and the
>firmware is being patched, so nobody should see it happen IRL? The consequences
>of the issue were:

I think this says it all, and therefore is not a quirk imo. We should not cater
to flat out spec violations (for non-public hw/fw) - there are plenty of things
that could easily break all over the place if bits are not set/unset by hardware
when it is supposed to.

So I would pretend this never occurred, and if someone ever complains (it was seen
IRL) we have your solution at hand.

>	- 1 CPU taken up
>	- driver can't be unbound since free_irq() waits for threads_active = 0
>
>2. Li Ming mentioned checking the return value of cxl_mem_get_event_records()
>is still valuable (currently a void function). So we could drop the other
>changes from the patch and just keep that part.

Yes, I agree.

Thanks,
Davidlohr