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: <8ce2ae38-51da-470b-9d3a-7408b79cf6e4@gmail.com>
Date: Sat, 10 Aug 2024 03:19:42 +0200
From: Maximilian Luz <luzmaximilian@...il.com>
To: Guenter Roeck <linux@...ck-us.net>
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 10:37 PM, Guenter Roeck wrote:
> 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.

No... you're completely right. "select" does make more sense.

I'll add a patch to change that for surface_fan as well for v3 (and then
I guess slowly update it for the other subsystems too).

Best regards,
Max

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ