linux-kernel - Re: [PATCH 1/4] hwmon: (asus-ec-sensors) introduce ec_board

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] [day] [month] [year] [list]

Message-ID: <679dfcda-a0b4-b420-b45b-2ccdc21a579d@roeck-us.net>
Date:   Wed, 30 Mar 2022 07:09:10 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Eugene Shalygin <eugene.shalygin@...il.com>
Cc:     darcagn@...tonmail.com, Jean Delvare <jdelvare@...e.com>,
        linux-hwmon@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] hwmon: (asus-ec-sensors) introduce ec_board_info
 struct for board data

On 3/30/22 00:51, Eugene Shalygin wrote:
> On Tue, 29 Mar 2022 at 22:28, Guenter Roeck <linux@...ck-us.net> wrote:
>>
>> On 3/29/22 12:22, Eugene Shalygin wrote:
>>> On Tue, 29 Mar 2022 at 15:44, Guenter Roeck <linux@...ck-us.net> wrote:
>>>>>
>>>>>     struct ec_sensors_data {
>>>>> -     unsigned long board_sensors;
>>>>> +     struct ec_board_info board_info;
>>>>
>>>> Please explain why this needs to be the entire structure and not
>>>> just a pointer to it.
>>>
>>> I marked the board_info array as __initconst assuming that this large
>>> array will be unloaded from memory after the init phase, while we keep
>>> only a single element. Is that assumption incorrect?
>>>
>>
>> What happens if you build the driver into the kernel and then instantiate
>> and de-instantiate it multiple times ?
> 
> Sorry, I have no idea because I don't know how to load a built-in
> driver multiple times. But since this driver is attached to a
> motherboard device, which is persistent and always single, do I need
> to consider such a scenario?
> 

Drivers have "unbind" and "bind" attributes, which can be used to unbind/bind
the driver mutliple times. That is quite useful for testing, including for
built-in drivers. As long as the attributes exists, they have to be supported.
This is not about having to consider a scenario, it is about preventing crashes
if existing functionality is used.

Having said that, I notice that the probe function is marked __init. I guess
I didn't pay attention. It may be interesting to build the driver into the
kernel, unbind/bind it, and see what happens.

Guenter