On Tue, Jun 15, 2021 at 9:01 PM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > On 14.06.21 13:48, Shravan, S wrote: > > Hi, > > > Why is it not a part of some generic subsystem under wireless network subsystem? > > > > -- This driver is instantiated only when the BIOS on given host exposes ACPI node corresponding to the BIOS SAR. This depends on support of the BIOS SAR feature by given OEM. > > -- It is agnostic of the wireless technology like WWAN, WiFi and BT. Hence, it is not made specific to any given wireless network subsystem. > > > > Please do let me know if you need more information. > > the problems I see here: > > 1. the device uapi is very vendor specific We have a platform profile which is also quite vendor specific, nevertheless we (as upstream) are trying to have points of unifications. I think this driver should be part of the corresponding profile / network subsystem part and be a one (of the) hardware implementation. Somebody can add more. Users in Linux should have a common ABI for that. And I'm not sure it should not be a netlink based one. > 2. its unclear for which air interface is the data really retrieved ? > 3. unclear how userland this should really handle in a generic way > --> how does it know which device to tune ? > 4. does it really need to be (non-portable) ioctls ? > > > by the way, who hat that funny idea putting such information into acpi > in such a weird way ? I believe its source is a Windows driver and Windows "culture", they simply don't give a crap about anything else and Windows is a product-oriented platform (each product is unique even if 99.9% of the hardware and firmware is the same with twenty more products). -- With Best Regards, Andy Shevchenko
