Messages in this thread | | | Date | Wed, 30 Mar 2022 07:09:10 -0700 | From | Guenter Roeck <> | 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@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
| |