Update stmpe.c accept chip ID 0x80 for STMPE610 variants

[KingHavok]

Some third-party STMPE610 clones (such as those used on Duinotech XC9022 2.8" TFT HATs sold by Jaycar Electronics) report a chip ID value of 0x80 instead of the expected 0x81. The current stmpe driver rejects these devices with:

stmpe-spi spi0.1: unknown chip id: 0x80
probe with driver stmpe-spi failed with error -22

This prevents the touchscreen sub-driver (stmpe-ts) from binding, leaving the resistive touch panel non-functional even though the hardware is otherwise compatible.

The fix is trivial: relax the ID check in stmpe_probe_id() to also accept 0x80 as a valid chip ID. With this change applied, the touchscreen initialises correctly and delivers input events as expected. Tested on a Raspberry Pi 5 running Raspberry Pi OS Bookworm with an XC9022 HAT.

This quirk should not impact other STMPE variants which continue to report 0x81.

[6by9]

If the ID value doesn't match then it isn't a STMPE610, and it should be using a compatible string that matches what it actually is rather than overloading the STMPE610 one.

I would expect to see a new enum value defined in enum stmpe_partnum to match whatever the chip is, and then also a struct stmpe_variant_info that would be nearly identical to stmpe610 but with the updated id_val.

Ideally all this should go upstream to the mainline Linux kernel as we have made no downstream modifications to it so far, and accepting patches increases the maintenance burden.