On sensors-detect (a zřejmě i drivery v kernelu) obecně ignorujou noťasové čipy EC (což je vlastně SuperIO obohacené o MCU jádro, typicky 80C51 nebo malý ARM) protože v nich běhá proprietární firmware, který může dělat ledacos. Přitom tihle EC švábi mívají podobný health monitoring subsystém, jako klasický SuperIO šváb bez MCU. SuperIO bez MCU jsou ovšem běžné spíš na desktopových a serverových motherboardech.
Kromě toho sensors-detect je skript z původních lm_sensors, a nedivil bych se, pokud maličko zatuchnul (poté co se drivery z projektu lm_sensors přestěhovaly do upstreamu na kernel.org. Takže třeba nemusí znát IDčka novějších čipů, které v driverech v kernelu de facto mohou mít podporu...
Třetí relevantní kousek softwaru je superiotool (původně z projektu coreboot). Ani on nezná nejnovější výdobytky a zřejmě moc neřeší EC (kvůli proprietárnímu FW, na noťasy podle mého coreboot tak snadno nacpat nejde). Zná ale jednotná "multiplexní vrátka ke konfiguračním registrům" a jejich odemykací sekvence u několika běžných výrobců SuperIO, a když mu dáte parametr -V, tak Vám i řekne, že tam nějakého švába našel, ale nezná jeho chip ID, takže ho ignoroval. No ale když víte vendora a chip ID, tak se dá ještě pohledat, jestli by se na to nechytil některý driver v kernelu. Bohužel tyhle HWMON drivery pro SuperIO šváby nepodléhají PnP. Asi protože nejsou na žádné PnP sběrnici. A nikoho kolem kernelu to netrápí natolik, aby tahle SuperIO konfigurační vrátka do nějakého PnP zapřáhnul.
Popravdě je to ještě trochu složitější... jedna multiplexní vrátka má SuperIO šváb pro svou vlastní konfiguraci (Configuration Registers, zkratka CR) - po těch jde superiotool. Jiná, svoje vlastní multiplexní vrátka (na jiné IO adrese) má samotný health monitor - po těch jde sensors-detect (kromě toho, že hledá na I2C, protože tam jsou health monitory tradičně taky vidět).
A ještě další multiplexní vrátka (i několikery) mívají EC švábi pro své další funkce. Ne všechny vnitřní periferní registry EC švába jsou přístupné z hostitelského CPU, a možná ne všechny (ale velká většina) jsou dostupné z interního MCU jádra EC. Některé registry mohou fungovat jako dual-ported "mailbox" pro komunikaci mezi EC MCU a hostitelským CPU = jejich význam pro hostitelský CPU je definován firmwarem EC MCU... Takže proprietární firmware na zapečeném MCU jádře, a pro jistotu datasheety pod NDA.
BTW že se ten ventilátor umoudřil je poměrně záhada :-) Možná se EC "učí" :-) Nebo se nově nainstalované Bubuntu potřebovalo zabydlet, postahovat aktualizace apod - a reálně Vám dneska žere míň procesoru než včera :-) Hypotézu že došlo k automatické aktualizaci BIOSu zamítám - tohle občas dělá aktualizátor výrobce pod Windows (nebo snad i Windows Update), ale pochybuju, že by Ubuntu konkrétně toto nějak řešilo.