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

Hi,

> 2026=E5=B9=B48=E6=9C=884=E6=97=A5 04:46=EF=BC=8CCorey Minyard =
<[email protected]> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> On Tue, Aug 04, 2026 at 12:55:53AM +0800, Miao Wang via B4 Relay =
wrote:
>> From: Miao Wang <[email protected]>
>>=20
>> 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.
>=20
> 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.
>=20
> For instance:
>=20
> config SENSORS_NPCM7XX
>        tristate "Nuvoton NPCM750 and compatible PWM and Fan =
controllers"
>        imply THERMAL
>=20
> 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.
>=20
> 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.
>=20
> 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 reason why I want to change this is that "select" here requires the
mfd part should also be compiled as built-in (i.e. =3D 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 =3Dm 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?

Cheers,

Miao Wang=