I noticed that when I connect the AC_Adapter to my Thinkpad X1 carbon that the fan went full-throttle and CPU temp goes up to 76C and maybe more if I let it.
Using top I saw "systemd-udevd" maxing out 2 cores.
"udevadm monitor" tells me it's bluetooth/hci connected ....
It turns out using
"sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket && sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket"
solves the problem ... until I connect again. Then it has to be run again or I simply dont run the start bit, but then I suspect I will not have bluetooth.

Hope this helps anyone having the same problem and ,maybe it'll be gone in newer kernel releases.

Edit:

Intrerestingly just using the stop command and resuming from suspend (using dpms) ..... if the touchpad is lost, using a previous solution:
"sudo modprobe -r psmouse;sudo modprobe psmouse" doesn't work. It requires a start of the sockets first.

It is (or was).
The laptop started having issues that it wouldn't shutdown through the OS i.e it kept booting up again spontaneously...as if the power button was stuck.

If I did shutdown the machine by holding the power button for a long time, it wouldn't boot at all without the reset button (a small hole in the bottom) and the resetting time and date in the BIOS -- as if the battery had disconnected.

Eventually I opened the machine and found another (very, very small) button, similar to the reset button near one of the hinges and after pressing that (5 sec or so) --- everything was back to normal after the next reboot.
"Normal" meaning no more systemd-udevd hogging the CPU and proper shutdown procedures.

Systemd and pulseaudio can due to wrong design consume alot of cpu and memory resurses.

Best way to solve this, specially for embedded systems is to remove then or shorten then out.

I have used many other Linux and -BSD system and there specially for Linux (latest CentOS7 or RedHat) systemd and pulseaudio has misbehaved in normal, suspend or hibernate or from resume, even from power up. It's not normal action to loop forever and consume too much cpu resources as the do today if wrong configuration. This can kill any embedded with battery support. Best solution is to do as MX linux (wrapper around) or better AntiX Linux (removed) do today. Then this wrong behavior is also removed. Previous version did not used systemd or pulseaudio. There are also problems with pulseaudio usage with increased latency dependent of audio source, my audio mixing software also misbehave and results will be trash.

In my case there was something wrong with the hardware or firmware (or both).
Doing a total reset of the motherboard (flush CMOS) solved the issue....but I have no idea what the reasons were or why, although I do suspect it has to do with how the "on/off" button is programmed in the firmware.

At the time, I searched around and it has happened to others albeit not many with no real clear cause.
The only thing I find sort of alike was an issue my daughters Thinkpad Helix2 sometimes had: It would freeze and on shutdown wouldn't boot up again, requiring a physical reset (through a little hole) of the motherboard.
The X1 carbon had a pinhole that didn't help but a second "CMOS-reset/clear" button hidden away on the MB eventually did the trick.
Since then I've never had the issue again ....so could be a kernel thingy