On Tue, Aug 04, 2026 at 05:40:14PM +0800, Miao Wang wrote: > Hi, > > > 2026年8月4日 04:46，Corey Minyard <[email protected]> 写道： > > > > On Tue, Aug 04, 2026 at 12:55:53AM +0800, Miao Wang via B4 Relay wrote: > >> From: Miao Wang <[email protected]> > >> > >> There is no strong dependency between the IPMI driver and its mfd > >> driver. Although the IPMI driver will not work without the mfd driver, > >> it is not a hard dependency. The IPMI driver can actually be compiled > >> without the mfd driver, and it will just fail to probe. When the mfd > >> driver is loaded, the IPMI driver will probe successfully. Therefore, > >> the dependency of the IPMI driver on its mfd driver should be relaxed > >> to "imply" from "select". This will allow the mfd driver to be compiled > >> as a module and the IPMI driver to be compiled as a part of the ipmi_si > >> module. The adjustment to Kconfig for the mfd driver will be introduced > >> in the later patch in this series. > > > > I don't think that's what "imply" is for. Imply seems to be for if > > there is another subsystem that can use this subsystem, but doesn't > > require it to exist. > > > > For instance: > > > > config SENSORS_NPCM7XX > > tristate "Nuvoton NPCM750 and compatible PWM and Fan controllers" > > imply THERMAL > > > > The fan controller will work fine without the thermal subsystem; you > > can control the fan speed without it. But the thermal subsystem is the > > logical user of this. I looked at many of these things like this. > > > > In the IPMI case, the IPMI driver is useless without the mfd part. So > > there's no point in compiling the IPMI part of this if the mfd part is > > not there. > > > > I could be wrong, but I can't see why you would want to do this. > > The mfd part and the IPMI part loosely depend on each other. Without the > IPMI part, the mfd part can still work to handle the display part. > Without the mfd part, the IPMI part is indeed useless, but it will not > generate compiling errors or other runtime errors. In the runtime, > the IPMI part can be actually loaded earlier than the mfd part. As a > result, their dependency is not that strong.
The operational dependency is strong, which is what I think you want to convey here. > > The reason why I want to change this is that "select" here requires the > mfd part should also be compiled as built-in (i.e. = y), since the > type of the configure entry IPMI_LS2K is bool. However, I cannot see > there is no other reason preventing the mfd driver from compiling as > a module. This patch series will introduce a minor fix, after which > the mfd driver will be capable to be compiled as a module. > > When the type of MFD_LS2K_BMC_CORE is changed to tristate, the "select" > here will prevent selecting =m for MFD_LS2K_BMC_CORE. I thus believe > that "select" here should be also changed. > > Any suggestions on declaring the dependency of the both parts? Ok, I understand now. Why can't the IPMI part be compiled as a module? Making that module-capable would be the right fix, I think. I can't see why that wouldn't work. IIRC, it was bool because the mfd part was bool. If you changed to imply, you would need a depends on the mfd core, BTW. Also, IPMI_LS2K needs a "depends on IPMI_SI" either way. I missed that earlier. Could you add that? Thanks, -corey > > Cheers, > > Miao Wang _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
