Process "irq/288-wcd9xxx" draining battery, how to stop it?

Question

I'm using a Fairphone 2 with Fairphone open OS, under Android 7, (build-number: fp2_sibon-userdebug 7.1.2 19.11.2 sibon-24df0be9), up to date. My battery loses systematically 50% to 90% overnight, and after having tried all sorts of things to stop it, my brother checked in a terminal (using Termux) with the top command which processes were using the CPU. A process named irq/288-wcd9xxx uses 15-20% of the CPU permanently, which could explain why my battery simply dies in 12 hours. Here's a screenshot of what I get.

As kill or kill -9 has absolutely no effect on it (it seems to work when running the command, but the process is still there afterwards), does anyone have any idea about what it is, and how to kill it, or stop it?

EDIT:

Thank you Irfan Latif for your detailed answer, my brother and me started having a look into this, and for the moment, not much improvement:

The command grep -rI $(readlink /proc/$(pgrep -f irq/288-wcd9xxx)/exe) /*/etc/init/ /init.*.rc indeed doesn't yield any output, and ppid is 2, so as you thought, it appears to be a kernel thread.
(We still had a look at the getprop | grep init.svc. list, and tried stopping audiod just to see, but it didn't change anything.)

As this phone is a Fairphone (modular phone), we can remove the suspect hardware and reboot to see if it changes anything (suggestion by this fairphone thread I posted too, actually already saying it's a "kernel process", hadn't understood the implications: It's hardware interrupts coming from the audio codec).
But removing hardware didn't appear to change anything either, maybe swapping will work (my brother has the same phone ‒with a different android version‒, we'll try next time we meet), but at this stage we doubt it.

Last, we will try soon your suggestions to control the CPU usage of the process, maybe it will be a temporary fix, but this now seems to my brother to need a full system re-installation, as from the moment we did the installation (the standard fairphone open OS install), the battery always appeared to be excessively draining.

P.S. Another process, irq/195-ngd_sli, seems to be eating up as well 5 to 7% permanently. We hadn't paid much attention to it, but it seems now just as abnormal; we'll dig this too.

Answer 1

irq looks something about hardware interrupts and wcd9xxx is a series of Qualcomm Aqstic audio codecs. So apparently irq/288-wcd9xxx process is running to support audio functionality on your device. The executable must be closed source binary blob, so there's nothing you can do to fix it, except (if already fixed by somebody, or) upgrading / downgrading the ROM or stopping the service.

As kill or kill -9 has absolutely no effect on it (it seems to work when running the command, but the process is still there afterwards), does anyone have any idea about what it is, and how to kill it, or stop it?

The process must be running as a native service defined by hardware / SoC vendor in some init's .rc file. So it will keep on restarting if killed. In order to properly stop the service you need to find its name. First get executable path from PID and then find service by searching through all .rc files:

~# grep -rI $(readlink /proc/$(pgrep -f irq/288-wcd9xxx)/exe) /*/etc/init/ /init.*.rc

You can confirm the same service name by looking at running status in getprop | grep init.svc. command. To stop the service use any of these commands:

~# stop <service_name>
~# setprop ctl.stop <service_name>

This needs to be repeated on every reboot. Or you may edit the related .rc file to remove the service.

If it results in something not working, another possibility is to try controlling its CPU usage by applying some limitation e.g. cgroups (if kernel supports).

EDIT:

I just noticed that a file name cannot have a slash (/). So irq/288-wcd9xxx must be a kernel thread for interrupt handling. It's not evident but you can check its parent PID (ppid must be 2) and also no memory allocation (0K) indicates that it's not a userspace process. So the problem is with your audio hardware or in-kernel driver (see this answer). In latter case again an updated kernel from OEM would fix the problem.

A workaround can be to control CPU usage of real-time process using chrt: chrt -r -p 1 $(pgrep -f irq/288-wcd9xxx) or chrt -f -p 1 $(pgrep -f irq/288-wcd9xxx) or renice or cgroups (if kernel supports): cpu or cpuset.