Hi, Response Inline. -----Original Message----- > From: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > Sent: Wednesday, June 16, 2021 1:59 AM > To: Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> > Cc: Shravan, S <s.shravan@xxxxxxxxx>; Hans de Goede <hdegoede@xxxxxxxxxx>; Mark Gross <mgross@xxxxxxxxxxxxxxx>; Platform Driver <platform-driver-x86@xxxxxxxxxxxxxxx>; An, Sudhakar <sudhakar.an@xxxxxxxxx> > Subject: Re: [PATCH 0/1] [x86] BIOS SAR Driver for M.2 Intel Modems > > 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. > [Shravan] This driver is exposing the SAR parameters solely influenced by the current status of the host platform and is not specific to any RF device. Hence it is placed at the path (Platform driver). Also, we have reworked the driver implementation to remove netlink usage. This is replaced with sysfs. Please do have a look and share feedback on the same. > > 2. its unclear for which air interface is the data really retrieved ? [Shravan] The initial implementation supports parameters received for WWAN. Subsequently other RF device types (Wifi, BT) will be supported. > > 3. unclear how userland this should really handle in a generic way > > --> how does it know which device to tune ? [Shravan] Userland will configure these parameters on the specific RF device. A Table of SAR parameters is already provisioned on the given RF device. The information retrieved from this driver specifies which index in this table has to be used by the RF device. > > 4. does it really need to be (non-portable) ioctls ? > > [Shravan] Usage of IOCTLs have been avoided in the latest patch. This has been replaced with sysfs. Please do have a look and suggest if this concern is addressed. > > > > 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). Thanks and Regards, Shravan S
