Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <679dfcda-a0b4-b420-b45b-2ccdc21a579d@roeck-us.net>
Date:   Wed, 30 Mar 2022 07:09:10 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
To:     Eugene Shalygin <eugene.shalygin@gmail.com>
Cc:     darcagn@protonmail.com, Jean Delvare <jdelvare@suse.com>,
        linux-hwmon@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20220327121404.1702631-1-eugene.shalygin@gmail.com>
 <20220327121404.1702631-2-eugene.shalygin@gmail.com>
 <16a36e23-bab2-4314-54ea-ff6b1011e6d7@roeck-us.net>
 <CAB95QATxYy5aj97P=S=L-kGE9dppuEbTYq=K=HGMBuZYVUBR4g@mail.gmail.com>
 <1239901b-9b4a-53ef-be86-1aa8337e0f31@roeck-us.net>
 <CAB95QAQGWRT=UsXPn65oiiwBRa1RKj61sg7wq9d7VntnFWzaOg@mail.gmail.com>
From:   Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH 1/4] hwmon: (asus-ec-sensors) introduce ec_board_info
 struct for board data
In-Reply-To: <CAB95QAQGWRT=UsXPn65oiiwBRa1RKj61sg7wq9d7VntnFWzaOg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/30/22 00:51, Eugene Shalygin wrote:
> On Tue, 29 Mar 2022 at 22:28, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 3/29/22 12:22, Eugene Shalygin wrote:
>>> On Tue, 29 Mar 2022 at 15:44, Guenter Roeck <linux@roeck-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