Adds driver for digital Honeywell ABP2 series of board mount
pressure and temperature sensors.

This driver differs quite a bit from the Honeywell ABP series that
is already present in the kernel:

- many more pressure-triplet variations of pressure ranges and
units
- extra end of conversion interrupt feature
- implements both i2c and SPI interfaces
- uses a bidirectional data retrieving protocol (4 wire SPI instead of 3 wire)
- 24+24bit resolution vs 14+11bit on the ABP

Specific low level i2c and spi data transfer API is used instead
of regmap because the protocol is based on simple commands instead
of on a memory map.

Given the fact that the sensor can perform gage and differential
pressure measurements with a full-scale range of down to 500 pascals
the offset and scale are calculated in such a way to provide a result
in pascals, not kilopascals. Just like the Honeywell MPR driver.
For a kilopascal output the scale representation would lose too much
precision.

Tested on two different sensors.

@Jonathan:

v2 moved the SPI tx buffer into the abp2_data struct and that opened a
debate on which buffer needs alignment and which doesn't.
my system is happy either way since it uses PIO mode all the time
even if DMA is implemented.
I've been told in the past [1] that the tx_buf needs to be DMA safe thus needs
to be IIO_DMA_MINALIGNed. also rx_buf has the same requirement.

[1] https://lore.kernel.org/linux-iio/20231220151305.00b4d1f0@jic23-huawei/

following this logic I have used the following code that covers all
requirements (I checked the two buffer's and the timestamp addresses):

--- 8< -----------------

struct abp2_data {
    struct device *dev;
[..]
    struct {
        u32 chan[2];
        aligned_s64 timestamp;
    } scan;
    u8 tx_buf[ABP2_MEASUREMENT_RD_SIZE] __aligned(IIO_DMA_MINALIGN);
    u8 rx_buf[ABP2_MEASUREMENT_RD_SIZE] __aligned(IIO_DMA_MINALIGN);
};
--- >8 -----------------

I am not sure why in many other drivers only one of the buffers is __aligned
and the second one is left dangling at a random alignment dictated by the sizeof
elements that precede it plus padding inside the struct.
how can that random aligned buffer be considered DMA safe?
and we are talking about a sizeable 64_byte_ alignment (for my armv7l arch).
it's very unlikely for a struct element to accidentally end up on a 64_byte_
alignment.

Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/basic-abp2-series/documents/sps-siot-abp2-series-datasheet-32350268-en.pdf
Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
---
v1 -> v2:
 - bindings are unchanged, added tag from Krzysztof
 - driver code changes based on Andy's feedback - detailed list in the respective patch

---
Petre Rodan (2):
      dt-bindings: iio: pressure: add honeywell,abp2030pa
      iio: pressure: add Honeywell ABP2 driver

 .../bindings/iio/pressure/honeywell,abp2030pa.yaml | 133 +++++
 MAINTAINERS                                        |   7 +
 drivers/iio/pressure/Kconfig                       |  31 ++
 drivers/iio/pressure/Makefile                      |   3 +
 drivers/iio/pressure/abp2030pa.c                   | 538 +++++++++++++++++++++
 drivers/iio/pressure/abp2030pa.h                   |  77 +++
 drivers/iio/pressure/abp2030pa_i2c.c               |  87 ++++
 drivers/iio/pressure/abp2030pa_spi.c               |  67 +++
 8 files changed, 943 insertions(+)
---
base-commit: f9e05791642810a0cf6237d39fafd6fec5e0b4bb
change-id: 20251122-honeywell_abp2_driver-9c796ef0c4b2

Best regards,
-- 
Petre Rodan <petre.rodan@subdimension.ro>