On 7/28/21 2:54 PM, Pali Rohár wrote:
On Wednesday 28 July 2021 23:40:21 Armin Wolf wrote:
Am 28.07.21 um 23:37 schrieb Guenter Roeck:
On 7/28/21 2:34 PM, Armin Wolf wrote:
Am 28.07.21 um 23:28 schrieb Guenter Roeck:
On 7/28/21 2:19 PM, Armin Wolf wrote:
On 28.07.21 23:07 Guenter Roeck wrote:
On 7/28/21 1:51 PM, W_Armin@xxxxxx wrote:
From: Armin Wolf <W_Armin@xxxxxx>
This patch series is converting the dell-smm-hwmon driver
to the new hwmon registration API. In order to do so,
it introduces a platform device in the first patch, and
applies some optimisations in the next three patches.
The switch to the new hwmon registration API is done in
the next patch. The last patch is fixing a small bug.
The caching of the fan/temp values was modified to better fit
the new hwmon API.
The patches work fine for my Dell Latitude C600, but i whould
appreciate someone testing the code on another model too.
Changes in v6:
- Make pwm1_enable permissions write-only
Sorry, guess I am missing something. Why ?
Guenter
pwm1_enable used SENSOR_DEVICE_ATTR_WO before the patch, so the file
permissions where 0200.
In the v5 patch series however, the file permission where not 0200,
so i
changed that.
Is there a _reason_ for declaring this attribute write only, other than
"it used to be that way" ?
Guenter
I dont think so, dell_smm_read will just return -EOPNOTSUPP if
someone tries to read pwm1_enable.
Armin
That is not what I meant. Is there a reason to not report
the current status of pwm1_enable to the user ? In other
words, does the firmware not report its current status ?
Guenter
Pali said the driver cannot query the state of pwm1_enable from the BIOS, and with userspace tools being able to change
the state of BIOS fan control behind our back, we cannot simply return the last set value.
We have already discussed this problem years ago, see:
https://lore.kernel.org/linux-hwmon/20160522152823.GA18331@xxxxxxxxxxxx/
And also again this year:
https://lore.kernel.org/linux-hwmon/20210528211037.2tnblovgb3rkcwnq@pali/
Basically there is no known firmware command to retrieve current status
yet. And both userspace and SMM/firmware itself can change state. So
kernel has no way how to retrieve current status and caching last value
cannot be used (due to userspace and firmware can change it).
Whole SMM API is undocumented and seems that Dell does not want to
provide any documentation for it.
I know that it is pity that we have no read functionality, but we have
to deal with it...
Maybe it would make sense to add comment into driver code, why attribute
is write-only...
Yes, please.
Thanks,
Guenter
