Re: [PATCH RFC v5 5/7] ipmi: ls2k: Relax the dependency to its mfd driver

[Corey Minyard <corey@minyard.net>]

On Tue, Aug 04, 2026 at 05:40:14PM +0800, Miao Wang wrote:
> Hi,
> 
> > 2026年8月4日 04:46，Corey Minyard <corey@minyard.net> 写道：
> > 
> > On Tue, Aug 04, 2026 at 12:55:53AM +0800, Miao Wang via B4 Relay wrote:
> >> From: Miao Wang <shankerwangmiao@gmail.com>
> >> 
> >> 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