Re: [PATCH v2] firmware: meson: sm: add stub functions when CONFIG_MESON_SM is disabled
Ronald Claveau <[email protected]>
| Newsgroups | org.infradead.lists.linux-amlogic,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <[email protected]> |
On 6/2/26 11:57 AM, Daniel Lezcano wrote: > On 5/31/26 21:58, Daniel Lezcano wrote: >> On 5/31/26 19:49, Ronald Claveau wrote: >>> On 5/31/26 10:41 AM, Daniel Lezcano wrote: >>>> On 5/31/26 09:51, Ronald Claveau via B4 Relay wrote: >>>>> From: Ronald Claveau <[email protected]> >> >> [ ... ] >> >>>>> +#if IS_ENABLED(CONFIG_MESON_SM) >>>>> + >>>>> struct meson_sm_firmware *meson_sm_get(struct device_node >>>>> *firmware_node); >>>>> int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 >>>>> *trim_info, >>>>> u32 tsensor_id); >>>> >>>> Do you really want to compile meson_sm as a module ? >>>> >>>> >>>> >>> >>> I don't want, but if I send a patch to change tristate to bool, it will >>> raise a warning because 'm' is not valid. >>> If it is accepted to ignore this warning, I can send another patch. >> > > [ ... ] > >> Compiling the firmware as a module means it must be loaded before the >> amlogic thermal driver, right ? Where is the dependency declared in >> the module ? >> >> If the sm_meson is in the platform, it should be selected as part of >> the platform's component. No need to have an option for that, no ? > > The questions remain and PR is approaching ... Sorry for the delay. The module issue was raised by the test robot here https://lore.kernel.org/oe-kbuild-all/[email protected]/ If I understand correctly we can drop this stub change and only use a "depends on MESON_SM" for the "AMLOGIC_THERMAL" config, is it correct ? -- Best regards, Ronald _______________________________________________ linux-amlogic mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-amlogic