[TOPIC-GPIO] Update the PCAL9535A driver and rename it to PCA95XX

[dcpleung]

This updates the PCAL9535A driver to the new GPIO API.

Also, rename the driver to PCA95XX since the driver can support that series of I2C-based GPIO expanders. Kconfig can be used to distinguish between variants.

Tested on the PCA9555 chip on the mec15xxevb_assy6853 board.

[dcpleung]

Relates to #18530

[pabigot]

IMO this really needs to be converted to use devicetree instead of Kconfig for all its features, and distinct compatibles used to identify variants, per #19904.

Looks pretty trivial: a standard i2c-device just like semtech,sx1409b but adding a has-pud boolean.

[dcpleung]

Updated to do DTS instead of Kconfigs. However, I cannot have multiple items in the compatible line in the binding, so I simply use "nxp,pca95xx" instead of actual chip model.

[pabigot]

I'm still focusing on devicetree support here, since I don't have hardware to test this. But can you confirm that your testing showed that both the 1pin and basic GPIO tests pass, as well as blinky and button (if appropriate)?

The native devicetree names should be used rather than the aliases that were necessary in the Kconfig era. I've noted substitutes for the first instance, but they should be applied to all instances.

If there's actually a need for so many instances you might look a drivers/counter/counter_nrfx_rtc.c for an example of a macro that generates all the instance-specific boilerplate just given the instance number.

[pabigot]

I cannot have multiple items in the compatible line in the binding

True; that'd require something like #20289.

You should be able to do:

compatible = "nxp,pca9555", "nxp,pca95xx";

in the devicetree source, though you'll get warnings from checkpatch until #19904 is settled.

[dcpleung]

Updated the driver to use 'DT_INST_*`. As for testing, I have only access to the mec15xx board with PCA9555. This variant does not support pull-up/pull-down so almost all test cases in the 1 pin test are skipped (except the LED toggle which works on the board). The driver does not support any interrupts so the button test would not work. The GPIO basic test, on the other hand, passed with the pull-up/pull-down and interrupt tests skipped.

[pabigot]

The code generally looks OK for the basic operations, but you should look at the sx1509b driver implementation for examples of:

• locking to prevent corrupting the configuration or output state if two threads try to manipulate the pins or configuration at the same time;
• checks to block operations from being initiated from within an ISR.

We don't document requirements for atomicity and interrupt-related behavior but for external controllers they can be a serious problem.

Also port-based configuration code can be dropped.

[zephyrbot]

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[mnkp]

@dcpleung thanks for the update. It would be really helpful if you removed redundant usage of access_op.

[mnkp]

LGTM, with a few minor comments.