From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E605E367B7B for ; Tue, 4 Aug 2026 11:39:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785843596; cv=none; b=LOpENtdAwwXJQK2TewhdU43s1Pnep7GtFErr4pR+dnaY2kjiWs58MeRWHeLz9bAdiYsR150dFoNvwrexf+a2ckfw+BSV7FtBjto6ebJFkqhHxvMGAv3Imuh/Y+9uQjl/Z0TfICgWylrY817ma2R5o8j4GeWoQTpX5YOIO9ViJFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785843596; c=relaxed/simple; bh=BQ7WHkmsN7sjhWQsoh8A1q3yCI/nauUkLzfd6bIzFqI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C7rv8RrqLqBAlsPGcHQuwfTh+jCjXKNbD/63ewvSy4m0uZzCkj0lHx8BOqd29eowfCjs/6oule7/hfTzkhYhZKX2JBDgoISju5ILV09R3C16CsznALq24sZ2ZKV0ZsAh0cjWhYDjLJY1oDvf0drNQ7xe4s37Ief6rri3yoM2cYg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net; spf=pass smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b=Swv9RvtG; arc=none smtp.client-ip=209.85.167.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b="Swv9RvtG" Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-495c49f8eccso2509351b6e.3 for ; Tue, 04 Aug 2026 04:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard.net; s=google; t=1785843592; x=1786448392; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:reply-to:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=9uh88uVU2Clp3KX7S7raepUOo/ZiMhFmmzr28cgkt3o=; b=Swv9RvtGr1uP9Nx0Nf3jS2EXIfeB6Nhrtv44E4pzkP+Zdf3DGGUx87+/ks2ZjMJhh6 MCAbgEaXQrIiN1nPNoaAlb2coajqQYuoSdqxiD1sKV2mJunzSE5doQb3aXDd7CCw8H/V ukayi3O+3NLiSI2HNpNeyGv0eNiTi6uqgAzeX6RhVwQsbGTPmvD6RadZviIqwQdKFwVV yho8ov/c5mwMMgVTNNfUoMX2f4vl3ndVN896oezTkgW3fp3kDXdIWulLLqvuVaf4OuJs 2syq/uEFCEosRUYnOnpwxEpqlXAahDDBYllkPmU2K03v/XnBG7tvklGkF7FY1GtjdB+P aU+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785843592; x=1786448392; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:reply-to:message-id:subject:cc :to:from:date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9uh88uVU2Clp3KX7S7raepUOo/ZiMhFmmzr28cgkt3o=; b=Eh9Fx7OxXJs7TDkX33P6zQO7x9a7d3RKm7Zz+uOzJcfxQg8aoE/zhyi41JnziIu2Jr ggf0gzkjPasMklrel3JA1ZtimU2lxSdeVbFq8BDWFSQ5TLIVgvGIZeo6I8FJCEU0enJq fyvFpBk3Wu7r0jXZLxMIHD1VZ37hSLKVTML6uiR1LM2orCWiuL5911OIkGLhUtbYrszL Bml+bdokZAQgbDPWHaPOnjpMd/i28jVLmT8E4vbHfum6aRVYKUEQoVmzZWek0AlUDdhE 4zInC6i4GiSUnsG0F07R7Q+S4wV9VVEjgyQCQqAGob7u+1phm3RK/AsyCrUZ8Ar1dwae Vbng== X-Forwarded-Encrypted: i=1; AHgh+RqF/lCnsxc4HZkCUQMXeNFHwDSlMHYQa9BVkYn/RV/xOpaOV0z01yNOGkcfxHYwnUkp8eVVtcJ2zHICmbQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyOljQZBtLIV+wE8IWTtjgc3k8PPEe0EbTYs5Eav6YilC2pOtqk aSav66rS+mvcDa+35rjv9Byd8fFlgTmZg7N/NZkF93oMM2xBgpzZQpweKfgou2w+OnA= X-Gm-Gg: AR+sD13WCzwtkw/8IUT8+bzLSXc3zx/IkJdZgejLxf3BbS2VssOC5XQcNltBcHuKxt2 Y1T44SU5v1fORtzj123/1WPez6RwIQYY/yv6EftPkgcv8nVvk549eRAgQPx7LUfcwZVdSm3uPII inmJisSphRoiIsFk8w1J5NX2uqS/OaB9k/D9rVCiOOOOZqAIURb0AYe/vhnCncFXkN0N17F9fBf vJhs5bv/caffiQXlWCxE0RZfephJszO+dqI0JJ/Vre0cFSF1EKEO1dySQNizKhlzuJQJamzEmB+ E+aSaKsgdOdLSlP5JLPywKiLMlu/uIf04l74+zkR3HDgsy06D9X3ZFEnq2pmtg4mvPX9vJtMikX J5/+lgGIjZwn6UsYhEZMSMEPxKnwFsvktIUSYFbY0rqyEdDHx8i9wt1A6+eiDiNg2K2Vd715nJL E0QhExGkSSn14PmQC4nPT/5+YkpXGvxbi6TsBMZppqTUXEYJYF2kDH5Ns+7c9qQhrVuk281DASX bXtYhcOnZlPn63GTFsAHvV5BJ619ezZaLRvLqlpybBsiPy8q91ZKIifnEKqNXpZMAeM4bcSyTbh DH24Is8Tug== X-Received: by 2002:a05:6808:2225:b0:4ab:230c:5faa with SMTP id 5614622812f47-4af5e3e5522mr19132771b6e.18.1785843592209; Tue, 04 Aug 2026 04:39:52 -0700 (PDT) Received: from mail.minyard.net ([2001:470:b8f6:1b:398b:b195:5c26:85bd]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4af58e9568asm8386849b6e.9.2026.08.04.04.39.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 04:39:50 -0700 (PDT) Date: Tue, 4 Aug 2026 06:39:46 -0500 From: Corey Minyard To: Miao Wang Cc: Binbin Zhou , Chong Qiao , Lee Jones , Huacai Chen , Linus Walleij , Bartosz Golaszewski , Xi Ruoyao , WANG Xuerui , Yinbo Zhu , Jiaxun Yang , mfd@lists.linux.dev, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, openipmi-developer@lists.sourceforge.net Subject: Re: [PATCH RFC v5 5/7] ipmi: ls2k: Relax the dependency to its mfd driver Message-ID: Reply-To: corey@minyard.net References: <20260804-ls2kbmc-mod-v5-0-e6bc5cdd9a93@gmail.com> <20260804-ls2kbmc-mod-v5-5-e6bc5cdd9a93@gmail.com> <2E268CDE-1D85-4611-BFF7-F74DD36132AB@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2E268CDE-1D85-4611-BFF7-F74DD36132AB@gmail.com> On Tue, Aug 04, 2026 at 05:40:14PM +0800, Miao Wang wrote: > Hi, > > > 2026年8月4日 04:46，Corey Minyard 写道： > > > > On Tue, Aug 04, 2026 at 12:55:53AM +0800, Miao Wang via B4 Relay wrote: > >> From: Miao Wang > >> > >> 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