Skip to content

Conversation

tolobis
Copy link
Contributor

@tolobis tolobis commented Aug 1, 2025

Prevent multiple callbacks on the interrupt pin. Only use one inpterrupt callback.
Fixing typos.
Code is test with a Tca9555 and Tca9554

Microsoft Reviewers: Open in CodeFlow

@dotnet-policy-service dotnet-policy-service bot added the area-device-bindings Device Bindings for audio, sensor, motor, and display hardware that can used with System.Device.Gpio label Aug 1, 2025
@@ -434,7 +434,12 @@ protected override void AddCallbackForPinValueChangedEvent(int pinNumber, PinEve

_interruptPins.Add(pinNumber, eventType);
_interruptLastInputValues.Add(pinNumber, Read(pinNumber));
_controller.RegisterCallbackForPinValueChangedEvent(_interrupt, PinEventTypes.Falling, InterruptHandler);

// Only register the callback if this is the first add callback
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you improve a comment a bit to clarify that we need to register interrupt once for host but this logic is for extender interrupts therefore the single handler will handle all extender interrupts registrations

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same for removal - it seems like many of us were confused about what's being fixed initially)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the comment so it should be now more clear why I register the callback for the interrupt only once

_controller.RegisterCallbackForPinValueChangedEvent(_interrupt, PinEventTypes.Falling, InterruptHandler);

// Only register the callback if this is the first add callback
if (_interruptPins.Count == 1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is not necessarily thread safe, but these checks are very likely to fail in any concurrent environment. Is it worth it to add a lock before these checks?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can lock (_interruptHandlerLock) as we do elsewhere for all register/deregister

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joperezr @krwq Thank you. I didnt see that in the first time. I added a lock around it.

Add lock on Add and Remove Callback
Copy link
Contributor

@raffaeler raffaeler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

_controller.RegisterCallbackForPinValueChangedEvent(_interrupt, PinEventTypes.Falling, InterruptHandler);
}

}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think _eventHandlers[pinNumber] = ... shuold also be inside the lock

{
_controller.RegisterCallbackForPinValueChangedEvent(_interrupt, PinEventTypes.Falling, InterruptHandler);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: extra enter

Copy link
Member

@krwq krwq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with small comment

@felixcollins
Copy link
Contributor

I think this should just sign up when the driver is created/disposed. See my implementation in #2417

Sorry, I didn't see this PR until just now.

@tolobis
Copy link
Contributor Author

tolobis commented Sep 3, 2025

I think this should just sign up when the driver is created/disposed. See my implementation in #2417

Sorry, I didn't see this PR until just now.

The #2417 PR looks good to me. Didn't see the other bugs. If you implement the interrupt lock we can close this PR an merge yours.

@felixcollins
Copy link
Contributor

I got carried away and made the TCA955x work better. I dropped my other PR and opened another #2420

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-device-bindings Device Bindings for audio, sensor, motor, and display hardware that can used with System.Device.Gpio
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants