linux-kernel - Re: [PATCH] hwmon: (corsair-psu) Fix failure to load when built-in to kernel

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 8 Dec 2023 10:34:45 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Aleksa Savic <savicaleksa83@...il.com>,
        Wilken Gottwalt <wilken.gottwalt@...teo.net>
Cc:     linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
Subject: Re: [PATCH] hwmon: (corsair-psu) Fix failure to load when built-in to
 kernel

On 12/8/23 08:52, Aleksa Savic wrote:
> On 2023-12-08 16:43:07 GMT+01:00, Guenter Roeck wrote:
>> On 12/8/23 05:57, Wilken Gottwalt wrote:
>>> On Fri, 8 Dec 2023 14:11:44 +0100
>>> Aleksa Savic <savicaleksa83@...il.com> wrote:
>>>
>>>> On 2023-12-08 14:07:10 GMT+01:00, Aleksa Savic wrote:
>>>>> When built-in to the kernel, the corsair-psu driver fails to register with
>>>>> the following message:
>>>>>
>>>>> "Driver 'corsair-psu' was unable to register with bus_type 'hid'
>>>>> because the bus was not initialized."
>>>>>
>>>>> Fix this by initializing the driver after the HID bus using
>>>>> late_initcall(), as hwmon is built before HID.
>>>>>
>>>>> Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver")
>>>>> Signed-off-by: Aleksa Savic <savicaleksa83@...il.com>
>>>>> ---
>>>>>    drivers/hwmon/corsair-psu.c | 15 ++++++++++++++-
>>>>>    1 file changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
>>>>> index 904890598c11..48831a528965 100644
>>>>> --- a/drivers/hwmon/corsair-psu.c
>>>>> +++ b/drivers/hwmon/corsair-psu.c
>>>>> @@ -899,7 +899,20 @@ static struct hid_driver corsairpsu_driver = {
>>>>>        .reset_resume    = corsairpsu_resume,
>>>>>    #endif
>>>>>    };
>>>>> -module_hid_driver(corsairpsu_driver);
>>>>> +
>>>>> +static int __init corsairpsu_hid_init(void)
>>>>> +{
>>>>> +    return hid_register_driver(&corsairpsu_driver);
>>>>> +}
>>>>> +
>>>>> +static void __exit corsairpsu_hid_exit(void)
>>>>> +{
>>>>> +    hid_unregister_driver(&corsairpsu_driver);
>>>>> +}
>>>>> +
>>>>> +/* When compiled into the kernel, initialize after the hid bus */
>>>>> +late_initcall(corsairpsu_hid_init);
>>>>> +module_exit(corsairpsu_hid_exit);
>>>>>      MODULE_LICENSE("GPL");
>>>>>    MODULE_AUTHOR("Wilken Gottwalt <wilken.gottwalt@...teo.net>");
>>>>
>>>>
>>>> Woops! Just saw that the same fix was sent yesterday. Please disregard, sorry!
>>>>
>>>> Aleksa
>>>
>>> It is fine. I just start to wonder if there was a change in the subsystem. I
>>> used the driver as built-in in the past for several months and never had that
>>> issue. And now it is a real flood of reports.
>>>
>>
>> Maybe there was a change in the build order, or some subtle change
>> in driver registration code. Question though is _when_ this changed.
>> It would be great if someone could bisect it. For example, bus registration
>> code has been changed significantly in v6.3. I am copying linux-input
>> and the hid maintainers for feedback.
> 
> The late_initcall() was also needed in 2020. when corsair-cpro was added in
> 40c3a4454225 ("hwmon: add Corsair Commander Pro driver").
> 
> There was also discussion on the list about it:
> 
> https://lore.kernel.org/all/3864498.z6qT3ff8q6@marius/
> 
> nzxt-smart2 (from the tail of 2021.) also has a comment about the message.
> 
> (Just providing references.)
> 

Ah yes, thanks for the reminder. We actually had a similar problem with
watchdog drivers and worked around it by deferring watchdog driver registration
until the watchdog core is initialized. That is of course just a kludge.
No idea if a clean(er) solution is even possible.

Guenter