drivers: gpio: retire pca95xx and pca953x driver

[CkovMk]

pca95xx and pca953x driver can be replaced by pca_series driver, which covers a larger number of devices.

This is a follow-on to #69333

[henrikbrixandersen]

Duplicate of #78273?

[CkovMk]

@henrikbrixandersen No, they are for different part_no, one for pca95xx anb one for pca953x. There are 2 drivers in zephyr tree. That's why I came up the idea to create an unified driver back then.

[henrikbrixandersen]

@henrikbrixandersen No, they are for different part_no, one for pca95xx anb one for pca953x. There are 2 drivers in zephyr tree. That's why I came up the idea to create an unified driver back then.

Could we handle them in the same PR, please? The comments for one of these will likely apply to both.

[CkovMk]

Sure, will merge into this pr. I'll also add other drivers that could be replaced into this pr.

[CkovMk]

Update: add support for PCA957x, PCAL953x and PCAL64xxA, retire original pcal64xxa driver.

Note: The original pcal64xxa driver supports "no-auto-reset" boolean property that preserves register content on reinitialization, but no code in zephyr tree is using it. Currently pca_series driver does not implement such feature, but should be easy to add. Let me know if such feature is required.

[rerickson1]

I think this change should make it in the release notes, etc. to highlight this.
Something to the effect of:
The old drivers were removed and replaced with an API equivalent driver that was already in the tree.

[dleach02]

@rerickson1 did @CkovMk update to release notes address your concern?

[CkovMk]

@dleach02 You may want to be cautious on approving / merging this pr. I don't have access to these boards that I've done changes on, so I cannot test my changes on real hardware. All I can guarantee is that this driver works for some part_no it claims compatible to (namely pca9538 and pcal6524) on i.MX 93 EVK, and I tested API for all GPIO_PCA_SERIES_FLAG_x configurations using pcal6524 to emulate other parts. (pcal6524 is "full-featured" and has all registers, can be used to emulate other parts ignoring the reg address difference.)

[dleach02]

@dleach02 You may want to be cautious on approving / merging this pr. I don't have access to these boards that I've done changes on, so I cannot test my changes on real hardware. All I can guarantee is that this driver works for some part_no it claims compatible to (namely pca9538 and pcal6524) on i.MX 93 EVK, and I tested API for all GPIO_PCA_SERIES_FLAG_x configurations using pcal6524 to emulate other parts. (pcal6524 is "full-featured" and has all registers, can be used to emulate other parts ignoring the reg address difference.)

I understand. Need to somehow move this PR along though so if there is a suggestion then please provide it.

[dleach02]

@CkovMk what do you want to do with this PR?

Awaiting disposition from author

[CkovMk]

@dleach02 To be honest I'm not sure what to do with these changes either. The drivers it's trying to replace works well enough on boards with them, and replacing them requires much testing efforts. Hopefully this pr would draw some attention from developers who are using old drivers, and they may want to give it a try. We can't force the deprecation, after all.

[dleach02]

actually, if appropriate, we can start the deprecation of these drivers. Zephyr has a process to do this. But if you don't want to take this on or don't have the means to test then lets close this PR.

[CkovMk]

let's close it then. I don't have resource to test boards from other vendor.

Please note this PR also contains some enablement code to devices it tends to replace. It's not added directly because I want to reuse existing "compatiable" statements. If other people take this task, this pr would serve as a reference.

Thanks!

[dleach02]

closing per request