All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Lee Jones <lee.jones@linaro.org>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Jean Delvare <jdelvare@suse.de>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Max Staudt <max@enpas.org>, Stefan Roese <sr@denx.de>,
	linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v3 3/3] mfd: ensure that AXP20X_I2C will have the right deps on X86
Date: Mon, 18 May 2020 14:53:02 +0200	[thread overview]
Message-ID: <20200518145302.56642b22@coco.lan> (raw)
In-Reply-To: <aa23c170-f4e8-e1f0-5c7f-35e51ec84533@redhat.com>

Em Mon, 18 May 2020 14:17:06 +0200
Hans de Goede <hdegoede@redhat.com> escreveu:

> Hi,
> 
> On 5/18/20 1:42 PM, Mauro Carvalho Chehab wrote:
> > The axp20x I2C driver can be used on X86, but also on ARM
> > platforms.
> > 
> > Yet, for X86, it has to be builtin and need ACPI OpRegion
> > support enabled.
> > 
> > So, the dependency chain is diferent for X86 and for other
> > archs.
> > 
> > Change the dependency chain to take this into consideration,
> > ensuring that everything will be set as it should.
> > 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>  
> 
> Hmm, last time we tried something like this (it was tried before,
> but in a bit different way) we ran into all kind of dependency /
> select cycles / issues.

Yeah, changes like that could cause troubles, specially where
select is used. With the approach I took, there's just one
new select for "IOSF_MBI".

I double-checked that, on most places, this feature is selected.
After this patch, there will be only three "depends on IOSF_MBI",
that could likely be also converted to "select":

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0ad7ad8cf8e1..d99ad532e17a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -740,7 +740,8 @@ config THINKPAD_ACPI_HOTKEY_POLL
 
 config INTEL_ATOMISP2_PM
 	tristate "Intel AtomISP2 dummy / power-management driver"
-	depends on PCI && IOSF_MBI && PM
+	depends on PCI && PM
+	select IOSF_MBI
 	help
 	  Power-management driver for Intel's Image Signal Processor found on
 	  Bay Trail and Cherry Trail devices. This dummy driver's sole purpose
@@ -1185,7 +1186,8 @@ config TOUCHSCREEN_DMI
 
 config INTEL_IMR
 	bool "Intel Isolated Memory Region support"
-	depends on X86_INTEL_QUARK && IOSF_MBI
+	depends on X86_INTEL_QUARK
+	select IOSF_MBI
 	---help---
 	  This option provides a means to manipulate Isolated Memory Regions.
 	  IMRs are a set of registers that define read and write access masks
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index dc1c1381d7fa..f4a3f110c720 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -21,7 +21,8 @@ config INTEL_RAPL_CORE
 
 config INTEL_RAPL
 	tristate "Intel RAPL Support via MSR Interface"
-	depends on X86 && IOSF_MBI
+	depends on X86
+	select IOSF_MBI
 	select INTEL_RAPL_CORE
 	---help---
 	  This enables support for the Intel Running Average Power Limit (RAPL)

The one for INTEL_IMR could even be dropped, as config 
X86_INTEL_QUARK already selects it too.

> With that said I'm fine with giving this another try, maybe let
> the test builders / rand config builds play with it for a while
> and see what happens?

Yeah, it makes sense to me.

Thanks,
Mauro

  reply	other threads:[~2020-05-18 12:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18 11:42 [PATCH v3 0/3] Fix dependencies for ACPI drivers with OpRegion settings Mauro Carvalho Chehab
2020-05-18 11:42 ` [PATCH v3 3/3] mfd: ensure that AXP20X_I2C will have the right deps on X86 Mauro Carvalho Chehab
2020-05-18 12:17   ` Hans de Goede
2020-05-18 12:53     ` Mauro Carvalho Chehab [this message]
2020-05-20 13:34       ` Wolfram Sang
2020-05-20 13:46         ` Jarkko Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200518145302.56642b22@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=hdegoede@redhat.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jdelvare@suse.de \
    --cc=krzk@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=max@enpas.org \
    --cc=rjw@rjwysocki.net \
    --cc=sr@denx.de \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.