Clean-up of the aw8695 haptic driver patchset that was sent in 2022.
Variables dependant on devicetree have been hardcoded, and unnecessary
functions have been removed.

Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Griffin Kroah-Hartman (1):
      dt-bindings: input: Add compatibility for Awinic AW8695

Luca Weiss (2):
      Input - aw8695: Add driver for AW8695 haptics
      arm64: dts: qcom: sm7225-fairphone-fp4: Add AW8695 haptics

 .../devicetree/bindings/input/awinic,aw86927.yaml  |   1 +
 arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts  |  26 +-
 drivers/input/misc/Kconfig                         |  11 +
 drivers/input/misc/Makefile                        |   1 +
 drivers/input/misc/aw8695.c                        | 753 +++++++++++++++++++++
 5 files changed, 791 insertions(+), 1 deletion(-)
---
base-commit: 5e036ce12de91c6fd674dad33b169c6150be2a7a
change-id: 20260716-aw8695_haptic_fp4_driver-397431e97638

Best regards,
-- 
Griffin Kroah-Hartman <griffin.kroah@fairphone.com>

On 9/14/26 11:37 AM, Griffin Kroah-Hartman wrote:
> Clean-up of the aw8695 haptic driver patchset that was sent in 2022.
> Variables dependant on devicetree have been hardcoded, and unnecessary
> functions have been removed.
> [..]

This looks similar to aw86927.c just with a somewhat different register 
layout, but there's even the same waveform and so on.

Could it be better / worth it to do everything in one driver (aw86927.c) 
and only have different register accessors per model but shared "logic" 
overall? Or would that make testing too annoying?

FWIW I've been trying to bring up aw86224 which has even fewer (but 
still *some*) differences to aw86927, so I'm potentially interested in 
having a unified base to add it to (when I figure out why it's stuck in 
overvoltage protection or whatever it was..)

Thanks,
~val

Hi Val,
On 9/15/26 06:14, Val Packett wrote:
> 
> On 9/14/26 11:37 AM, Griffin Kroah-Hartman wrote:
>> Clean-up of the aw8695 haptic driver patchset that was sent in 2022.
>> Variables dependant on devicetree have been hardcoded, and unnecessary
>> functions have been removed.
>> [..]
> 
> This looks similar to aw86927.c just with a somewhat different register 
> layout, but there's even the same waveform and so on.
> 
> Could it be better / worth it to do everything in one driver (aw86927.c) 
> and only have different register accessors per model but shared "logic" 
> overall? Or would that make testing too annoying?

You're totally right with the similarities, and the original idea was to
add on to the '27s driver, unfortunately the register layouts are too 
different for it to be worth it.

> FWIW I've been trying to bring up aw86224 which has even fewer (but 
> still *some*) differences to aw86927, so I'm potentially interested in 
> having a unified base to add it to (when I figure out why it's stuck in 
> overvoltage protection or whatever it was..)

After a brief glance at the register layout for the aw86224, it totally 
seems compatible with the aw86927, lots of shared registers, so I 
definitely think that your approach is the way to go there.

> Thanks,
> ~val

Good luck with the aw869224!

Best,
Griffin