linux-kernel - Re: [PATCH v2] hwmon: Add thermal sensor driver for Surface Aggregator Module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <851fe373-471e-4892-addb-343d84334daa@roeck-us.net>
Date: Wed, 7 Aug 2024 13:37:27 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Maximilian Luz <luzmaximilian@...il.com>
Cc: Jean Delvare <jdelvare@...e.com>, Hans de Goede <hdegoede@...hat.com>,
 Ivor Wanders <ivor@...nders.net>, linux-kernel@...r.kernel.org,
 linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v2] hwmon: Add thermal sensor driver for Surface
 Aggregator Module

On 8/7/24 13:11, Maximilian Luz wrote:
> On 8/7/24 9:50 PM, Guenter Roeck wrote:
>> On 8/7/24 12:25, Maximilian Luz wrote:
>>> On 8/7/24 2:32 AM, Guenter Roeck wrote:
>>>> On 8/4/24 16:08, Maximilian Luz wrote:
>>>
>>> [...]
>>>
>>>>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>>>>> index b60fe2e58ad6..70c6385f0ed6 100644
>>>>> --- a/drivers/hwmon/Kconfig
>>>>> +++ b/drivers/hwmon/Kconfig
>>>>> @@ -2080,6 +2080,16 @@ config SENSORS_SURFACE_FAN
>>>>>         Select M or Y here, if you want to be able to read the fan's speed.
>>>>> +config SENSORS_SURFACE_TEMP
>>>>> +    tristate "Microsoft Surface Thermal Sensor Driver"
>>>>> +    depends on SURFACE_AGGREGATOR
>>>>
>>>> As the kernel test robot points out, this dependency is wrong.
>>>> __ssam_device_driver_register() is only available
>>>> if SURFACE_AGGREGATOR_BUS is enabled.
>>>
>>> Right, I should have spotted this before submission, sorry. This should
>>> be
>>>
>>>    depends on SURFACE_AGGREGATOR
>>>    depends on SURFACE_AGGREGATOR_BUS
>>>
>>
>> SURFACE_AGGREGATOR_BUS already depends on SURFACE_AGGREGATOR, so the extra
>> dependency is not needed.
> 
> Unfortunately, SURFACE_AGGREGATOR_BUS is a bool and SURFACE_AGGREGATOR
> tri-state, and the inference of whether SURFACE_AGGREGATOR needs to be
> built in or not breaks because of that. Meaning we could have something
> like
> 
>      SENSORS_SURFACE_TEMP=y      (tri-state, module)
>      SURFACE_AGGREGATOR_BUS=y    (bool, optional-code-flag)
>      SURFACE_AGGREGATOR=m        (tri-state, module)
> 
> because SURFACE_AGGREGATOR_BUS is fine with either m or y. But in
> reality, SENSORS_SURFACE_TEMP=y would require SURFACE_AGGREGATOR=y.
> 

Ah yes, I can see that the double dependency is there everywhere. Normally I'd
have assumed that to be handled with SURFACE_AGGREGATOR_BUS as non-configurable
option and its users selecting it, i.e.,

	depends on SURFACE_AGGREGATOR
	select SURFACE_AGGREGATOR_BUS

but, sure, it is your call to make SURFACE_AGGREGATOR_BUS a configurable
(instead of selectable) option. I don't understand the benefit of being able
to enable SURFACE_AGGREGATOR_BUS without any users, but then maybe I just
don't have sufficient understanding of the context.

Thanks,
Guenter