* [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
@ 2023-06-06 14:00 Zhang Rui
2023-06-06 15:45 ` kernel test robot
2023-06-06 16:17 ` kernel test robot
0 siblings, 2 replies; 10+ messages in thread
From: Zhang Rui @ 2023-06-06 14:00 UTC (permalink / raw)
To: linux-pm, rafael.j.wysocki, daniel.lezcano; +Cc: linux-kernel, arnd
After commit 3382388d7148 ("intel_rapl: abstract RAPL common code"),
accessing to IOSF_MBI interface is done in the RAPL common code.
Thus it is the CONFIG_INTEL_RAPL_CORE that has dependency of
CONFIG_IOSF_MBI, while CONFIG_INTEL_RAPL_MSR does not.
This problem was not exposed previously because all the previous RAPL
common code users, aka, the RAPL MSR and MMIO I/F drivers, have
CONFIG_IOSF_MBI selected.
Fix the CONFIG_IOSF_MBI dependency in RAPL code. This also fixes a build
time failure when the RAPL TPMI I/F driver is introduced without
selecting CONFIG_IOSF_MBI.
x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to `iosf_mbi_write'
x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined reference to `iosf_mbi_read'
Reference to iosf_mbi.h is also removed from the RAPL MSR I/F driver.
Fixes: 3382388d7148 ("intel_rapl: abstract RAPL common code")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/all/20230601213246.3271412-1-arnd@kernel.org
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
drivers/powercap/Kconfig | 4 +++-
drivers/powercap/intel_rapl_msr.c | 1 -
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index 90d33cd1b670..b063f7511773 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -18,10 +18,12 @@ if POWERCAP
# Client driver configurations go here.
config INTEL_RAPL_CORE
tristate
+ depends on PCI
+ select IOSF_MBI
config INTEL_RAPL
tristate "Intel RAPL Support via MSR Interface"
- depends on X86 && IOSF_MBI
+ depends on X86 && PCI
select INTEL_RAPL_CORE
help
This enables support for the Intel Running Average Power Limit (RAPL)
diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c
index a27673706c3d..be118d46f32e 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -22,7 +22,6 @@
#include <linux/processor.h>
#include <linux/platform_device.h>
-#include <asm/iosf_mbi.h>
#include <asm/cpu_device_id.h>
#include <asm/intel-family.h>
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
2023-06-06 14:00 [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency Zhang Rui
@ 2023-06-06 15:45 ` kernel test robot
2023-06-07 2:22 ` Zhang, Rui
2023-06-06 16:17 ` kernel test robot
1 sibling, 1 reply; 10+ messages in thread
From: kernel test robot @ 2023-06-06 15:45 UTC (permalink / raw)
To: Zhang Rui, linux-pm, rafael.j.wysocki, daniel.lezcano
Cc: llvm, oe-kbuild-all, linux-kernel, arnd
Hi Zhang,
kernel test robot noticed the following build errors:
[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on next-20230606]
[cannot apply to linus/master v6.4-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zhang-Rui/powercap-intel_rapl-Fix-CONFIG_IOSF_MBI-dependency/20230606-220222
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link: https://lore.kernel.org/r/20230606140000.385223-1-rui.zhang%40intel.com
patch subject: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
config: i386-randconfig-i011-20230606 (attached as .config)
compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
reproduce (this is a W=1 build):
mkdir -p ~/bin
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add rafael-pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git fetch rafael-pm linux-next
git checkout rafael-pm/linux-next
b4 shazam https://lore.kernel.org/r/20230606140000.385223-1-rui.zhang@intel.com
# save the config file
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1 ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1 ARCH=i386
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306062334.5Z1NkD1F-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/Kconfig:674:error: recursive dependency detected!
arch/x86/Kconfig:674: symbol IOSF_MBI is selected by INTEL_RAPL_CORE
drivers/powercap/Kconfig:19: symbol INTEL_RAPL_CORE is selected by INTEL_RAPL_TPMI
drivers/powercap/Kconfig:38: symbol INTEL_RAPL_TPMI depends on IOSF_MBI
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
vim +674 arch/x86/Kconfig
506f1d07b31081 Sam Ravnborg 2007-11-09 592
ddd70cf93d784a Jun Nakajima 2013-01-21 593 config X86_GOLDFISH
ddd70cf93d784a Jun Nakajima 2013-01-21 594 bool "Goldfish (Virtual Platform)"
cb7b80237a9f41 Ben Hutchings 2013-06-24 595 depends on X86_EXTENDED_PLATFORM
a7f7f6248d9740 Masahiro Yamada 2020-06-14 596 help
ddd70cf93d784a Jun Nakajima 2013-01-21 597 Enable support for the Goldfish virtual platform used primarily
ddd70cf93d784a Jun Nakajima 2013-01-21 598 for Android development. Unless you are building for the Android
ddd70cf93d784a Jun Nakajima 2013-01-21 599 Goldfish emulator say N here.
ddd70cf93d784a Jun Nakajima 2013-01-21 600
c751e17b5371ad Thomas Gleixner 2010-11-09 601 config X86_INTEL_CE
c751e17b5371ad Thomas Gleixner 2010-11-09 602 bool "CE4100 TV platform"
c751e17b5371ad Thomas Gleixner 2010-11-09 603 depends on PCI
c751e17b5371ad Thomas Gleixner 2010-11-09 604 depends on PCI_GODIRECT
6084a6e23c971e Jiang Liu 2014-06-09 605 depends on X86_IO_APIC
c751e17b5371ad Thomas Gleixner 2010-11-09 606 depends on X86_32
c751e17b5371ad Thomas Gleixner 2010-11-09 607 depends on X86_EXTENDED_PLATFORM
37bc9f5078c62b Dirk Brandewie 2010-11-09 608 select X86_REBOOTFIXUPS
da6b737b9ab768 Sebastian Andrzej Siewior 2011-02-22 609 select OF
da6b737b9ab768 Sebastian Andrzej Siewior 2011-02-22 610 select OF_EARLY_FLATTREE
a7f7f6248d9740 Masahiro Yamada 2020-06-14 611 help
c751e17b5371ad Thomas Gleixner 2010-11-09 612 Select for the Intel CE media processor (CE4100) SOC.
c751e17b5371ad Thomas Gleixner 2010-11-09 613 This option compiles in support for the CE4100 SOC for settop
c751e17b5371ad Thomas Gleixner 2010-11-09 614 boxes and media devices.
c751e17b5371ad Thomas Gleixner 2010-11-09 615
4cb9b00f42e078 David Cohen 2013-12-16 616 config X86_INTEL_MID
43605ef188cd39 Alan Cox 2011-07-12 617 bool "Intel MID platform support"
43605ef188cd39 Alan Cox 2011-07-12 618 depends on X86_EXTENDED_PLATFORM
edc6bc784028f2 David Cohen 2014-01-21 619 depends on X86_PLATFORM_DEVICES
1ea7c6737c8f68 Alan Cox 2011-11-10 620 depends on PCI
3fda5bb420e79b Andy Shevchenko 2016-01-15 621 depends on X86_64 || (PCI_GOANY && X86_32)
1ea7c6737c8f68 Alan Cox 2011-11-10 622 depends on X86_IO_APIC
4cb9b00f42e078 David Cohen 2013-12-16 623 select I2C
7c9c3a1e5fc872 Alan Cox 2011-12-29 624 select DW_APB_TIMER
54b34aa0a7295c Mika Westerberg 2020-04-16 625 select INTEL_SCU_PCI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 626 help
4cb9b00f42e078 David Cohen 2013-12-16 627 Select to build a kernel capable of supporting Intel MID (Mobile
4cb9b00f42e078 David Cohen 2013-12-16 628 Internet Device) platform systems which do not have the PCI legacy
4cb9b00f42e078 David Cohen 2013-12-16 629 interfaces. If you are building for a PC class system say N here.
1ea7c6737c8f68 Alan Cox 2011-11-10 630
4cb9b00f42e078 David Cohen 2013-12-16 631 Intel MID platforms are based on an Intel processor and chipset which
4cb9b00f42e078 David Cohen 2013-12-16 632 consume less power than most of the x86 derivatives.
43605ef188cd39 Alan Cox 2011-07-12 633
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 634 config X86_INTEL_QUARK
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 635 bool "Intel Quark platform support"
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 636 depends on X86_32
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 637 depends on X86_EXTENDED_PLATFORM
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 638 depends on X86_PLATFORM_DEVICES
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 639 depends on X86_TSC
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 640 depends on PCI
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 641 depends on PCI_GOANY
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 642 depends on X86_IO_APIC
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 643 select IOSF_MBI
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 644 select INTEL_IMR
9ab6eb51ef4ad6 Andy Shevchenko 2015-03-05 645 select COMMON_CLK
a7f7f6248d9740 Masahiro Yamada 2020-06-14 646 help
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 647 Select to include support for Quark X1000 SoC.
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 648 Say Y here if you have a Quark based system such as the Arduino
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 649 compatible Intel Galileo.
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 650
3d48aab1d5035f Mika Westerberg 2013-01-18 651 config X86_INTEL_LPSS
3d48aab1d5035f Mika Westerberg 2013-01-18 652 bool "Intel Low Power Subsystem Support"
5962dd22f0ff6f Sinan Kaya 2019-01-02 653 depends on X86 && ACPI && PCI
3d48aab1d5035f Mika Westerberg 2013-01-18 654 select COMMON_CLK
0f531431d3de88 Mathias Nyman 2013-09-13 655 select PINCTRL
eebb3e8d8aaf28 Andy Shevchenko 2015-12-12 656 select IOSF_MBI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 657 help
3d48aab1d5035f Mika Westerberg 2013-01-18 658 Select to build support for Intel Low Power Subsystem such as
3d48aab1d5035f Mika Westerberg 2013-01-18 659 found on Intel Lynxpoint PCH. Selecting this option enables
0f531431d3de88 Mathias Nyman 2013-09-13 660 things like clock tree (common clock framework) and pincontrol
0f531431d3de88 Mathias Nyman 2013-09-13 661 which are needed by the LPSS peripheral drivers.
3d48aab1d5035f Mika Westerberg 2013-01-18 662
92082a8886f30a Ken Xue 2015-02-06 663 config X86_AMD_PLATFORM_DEVICE
92082a8886f30a Ken Xue 2015-02-06 664 bool "AMD ACPI2Platform devices support"
92082a8886f30a Ken Xue 2015-02-06 665 depends on ACPI
92082a8886f30a Ken Xue 2015-02-06 666 select COMMON_CLK
92082a8886f30a Ken Xue 2015-02-06 667 select PINCTRL
a7f7f6248d9740 Masahiro Yamada 2020-06-14 668 help
92082a8886f30a Ken Xue 2015-02-06 669 Select to interpret AMD specific ACPI device to platform device
92082a8886f30a Ken Xue 2015-02-06 670 such as I2C, UART, GPIO found on AMD Carrizo and later chipsets.
92082a8886f30a Ken Xue 2015-02-06 671 I2C and UART depend on COMMON_CLK to set clock. GPIO driver is
92082a8886f30a Ken Xue 2015-02-06 672 implemented under PINCTRL subsystem.
92082a8886f30a Ken Xue 2015-02-06 673
ced3ce760b8df0 David E. Box 2014-09-17 @674 config IOSF_MBI
ced3ce760b8df0 David E. Box 2014-09-17 675 tristate "Intel SoC IOSF Sideband support for SoC platforms"
ced3ce760b8df0 David E. Box 2014-09-17 676 depends on PCI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 677 help
ced3ce760b8df0 David E. Box 2014-09-17 678 This option enables sideband register access support for Intel SoC
ced3ce760b8df0 David E. Box 2014-09-17 679 platforms. On these platforms the IOSF sideband is used in lieu of
ced3ce760b8df0 David E. Box 2014-09-17 680 MSR's for some register accesses, mostly but not limited to thermal
ced3ce760b8df0 David E. Box 2014-09-17 681 and power. Drivers may query the availability of this device to
ced3ce760b8df0 David E. Box 2014-09-17 682 determine if they need the sideband in order to work on these
ced3ce760b8df0 David E. Box 2014-09-17 683 platforms. The sideband is available on the following SoC products.
ced3ce760b8df0 David E. Box 2014-09-17 684 This list is not meant to be exclusive.
ced3ce760b8df0 David E. Box 2014-09-17 685 - BayTrail
ced3ce760b8df0 David E. Box 2014-09-17 686 - Braswell
ced3ce760b8df0 David E. Box 2014-09-17 687 - Quark
ced3ce760b8df0 David E. Box 2014-09-17 688
ced3ce760b8df0 David E. Box 2014-09-17 689 You should say Y if you are running a kernel on one of these SoC's.
ced3ce760b8df0 David E. Box 2014-09-17 690
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
2023-06-06 15:45 ` kernel test robot
@ 2023-06-07 2:22 ` Zhang, Rui
2023-06-12 17:50 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Zhang, Rui @ 2023-06-07 2:22 UTC (permalink / raw)
To: linux-pm@vger.kernel.org, Wysocki, Rafael J,
daniel.lezcano@linaro.org, lkp
Cc: llvm@lists.linux.dev, linux-kernel@vger.kernel.org,
oe-kbuild-all@lists.linux.dev, arnd@arndb.de
On Tue, 2023-06-06 at 23:45 +0800, kernel test robot wrote:
> Hi Zhang,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on rafael-pm/linux-next]
> [also build test ERROR on next-20230606]
> [cannot apply to linus/master v6.4-rc5]
> [If your patch is applied to the wrong git tree, kindly drop us a
> note.
> And when submitting patch, we suggest to use '--base' as documented
> in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Zhang-Rui/powercap-intel_rapl-Fix-CONFIG_IOSF_MBI-dependency/20230606-220222
This is a false alarm from the robot.
It applied Arnd' patch first and then applied this patch on top.
I think we can ignore the lkp robot warnings for this thread.
thanks,
rui
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
2023-06-07 2:22 ` Zhang, Rui
@ 2023-06-12 17:50 ` Rafael J. Wysocki
0 siblings, 0 replies; 10+ messages in thread
From: Rafael J. Wysocki @ 2023-06-12 17:50 UTC (permalink / raw)
To: Zhang, Rui
Cc: linux-pm@vger.kernel.org, Wysocki, Rafael J,
daniel.lezcano@linaro.org, lkp, llvm@lists.linux.dev,
linux-kernel@vger.kernel.org, oe-kbuild-all@lists.linux.dev,
arnd@arndb.de
On Wed, Jun 7, 2023 at 4:23 AM Zhang, Rui <rui.zhang@intel.com> wrote:
>
> On Tue, 2023-06-06 at 23:45 +0800, kernel test robot wrote:
> > Hi Zhang,
> >
> > kernel test robot noticed the following build errors:
> >
> > [auto build test ERROR on rafael-pm/linux-next]
> > [also build test ERROR on next-20230606]
> > [cannot apply to linus/master v6.4-rc5]
> > [If your patch is applied to the wrong git tree, kindly drop us a
> > note.
> > And when submitting patch, we suggest to use '--base' as documented
> > in
> > https://git-scm.com/docs/git-format-patch#_base_tree_information]
> >
> > url:
> > https://github.com/intel-lab-lkp/linux/commits/Zhang-Rui/powercap-intel_rapl-Fix-CONFIG_IOSF_MBI-dependency/20230606-220222
>
> This is a false alarm from the robot.
> It applied Arnd' patch first and then applied this patch on top.
>
> I think we can ignore the lkp robot warnings for this thread.
OK
Applied as 6.5 material, thanks!
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
2023-06-06 14:00 [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency Zhang Rui
2023-06-06 15:45 ` kernel test robot
@ 2023-06-06 16:17 ` kernel test robot
1 sibling, 0 replies; 10+ messages in thread
From: kernel test robot @ 2023-06-06 16:17 UTC (permalink / raw)
To: Zhang Rui, linux-pm, rafael.j.wysocki, daniel.lezcano
Cc: oe-kbuild-all, linux-kernel, arnd
Hi Zhang,
kernel test robot noticed the following build errors:
[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on next-20230606]
[cannot apply to linus/master v6.4-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Zhang-Rui/powercap-intel_rapl-Fix-CONFIG_IOSF_MBI-dependency/20230606-220222
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link: https://lore.kernel.org/r/20230606140000.385223-1-rui.zhang%40intel.com
patch subject: [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency
config: i386-randconfig-r003-20230606 (attached as .config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build):
git remote add rafael-pm https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
git fetch rafael-pm linux-next
git checkout rafael-pm/linux-next
b4 shazam https://lore.kernel.org/r/20230606140000.385223-1-rui.zhang@intel.com
# save the config file
make W=1 ARCH=i386 olddefconfig
make W=1 ARCH=i386
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306070006.kzS17w6a-lkp@intel.com/
All errors (new ones prefixed by >>):
>> arch/x86/Kconfig:674:error: recursive dependency detected!
arch/x86/Kconfig:674: symbol IOSF_MBI is selected by INTEL_RAPL_CORE
drivers/powercap/Kconfig:19: symbol INTEL_RAPL_CORE is selected by INTEL_RAPL_TPMI
drivers/powercap/Kconfig:38: symbol INTEL_RAPL_TPMI depends on IOSF_MBI
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
vim +674 arch/x86/Kconfig
506f1d07b31081 Sam Ravnborg 2007-11-09 592
ddd70cf93d784a Jun Nakajima 2013-01-21 593 config X86_GOLDFISH
ddd70cf93d784a Jun Nakajima 2013-01-21 594 bool "Goldfish (Virtual Platform)"
cb7b80237a9f41 Ben Hutchings 2013-06-24 595 depends on X86_EXTENDED_PLATFORM
a7f7f6248d9740 Masahiro Yamada 2020-06-14 596 help
ddd70cf93d784a Jun Nakajima 2013-01-21 597 Enable support for the Goldfish virtual platform used primarily
ddd70cf93d784a Jun Nakajima 2013-01-21 598 for Android development. Unless you are building for the Android
ddd70cf93d784a Jun Nakajima 2013-01-21 599 Goldfish emulator say N here.
ddd70cf93d784a Jun Nakajima 2013-01-21 600
c751e17b5371ad Thomas Gleixner 2010-11-09 601 config X86_INTEL_CE
c751e17b5371ad Thomas Gleixner 2010-11-09 602 bool "CE4100 TV platform"
c751e17b5371ad Thomas Gleixner 2010-11-09 603 depends on PCI
c751e17b5371ad Thomas Gleixner 2010-11-09 604 depends on PCI_GODIRECT
6084a6e23c971e Jiang Liu 2014-06-09 605 depends on X86_IO_APIC
c751e17b5371ad Thomas Gleixner 2010-11-09 606 depends on X86_32
c751e17b5371ad Thomas Gleixner 2010-11-09 607 depends on X86_EXTENDED_PLATFORM
37bc9f5078c62b Dirk Brandewie 2010-11-09 608 select X86_REBOOTFIXUPS
da6b737b9ab768 Sebastian Andrzej Siewior 2011-02-22 609 select OF
da6b737b9ab768 Sebastian Andrzej Siewior 2011-02-22 610 select OF_EARLY_FLATTREE
a7f7f6248d9740 Masahiro Yamada 2020-06-14 611 help
c751e17b5371ad Thomas Gleixner 2010-11-09 612 Select for the Intel CE media processor (CE4100) SOC.
c751e17b5371ad Thomas Gleixner 2010-11-09 613 This option compiles in support for the CE4100 SOC for settop
c751e17b5371ad Thomas Gleixner 2010-11-09 614 boxes and media devices.
c751e17b5371ad Thomas Gleixner 2010-11-09 615
4cb9b00f42e078 David Cohen 2013-12-16 616 config X86_INTEL_MID
43605ef188cd39 Alan Cox 2011-07-12 617 bool "Intel MID platform support"
43605ef188cd39 Alan Cox 2011-07-12 618 depends on X86_EXTENDED_PLATFORM
edc6bc784028f2 David Cohen 2014-01-21 619 depends on X86_PLATFORM_DEVICES
1ea7c6737c8f68 Alan Cox 2011-11-10 620 depends on PCI
3fda5bb420e79b Andy Shevchenko 2016-01-15 621 depends on X86_64 || (PCI_GOANY && X86_32)
1ea7c6737c8f68 Alan Cox 2011-11-10 622 depends on X86_IO_APIC
4cb9b00f42e078 David Cohen 2013-12-16 623 select I2C
7c9c3a1e5fc872 Alan Cox 2011-12-29 624 select DW_APB_TIMER
54b34aa0a7295c Mika Westerberg 2020-04-16 625 select INTEL_SCU_PCI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 626 help
4cb9b00f42e078 David Cohen 2013-12-16 627 Select to build a kernel capable of supporting Intel MID (Mobile
4cb9b00f42e078 David Cohen 2013-12-16 628 Internet Device) platform systems which do not have the PCI legacy
4cb9b00f42e078 David Cohen 2013-12-16 629 interfaces. If you are building for a PC class system say N here.
1ea7c6737c8f68 Alan Cox 2011-11-10 630
4cb9b00f42e078 David Cohen 2013-12-16 631 Intel MID platforms are based on an Intel processor and chipset which
4cb9b00f42e078 David Cohen 2013-12-16 632 consume less power than most of the x86 derivatives.
43605ef188cd39 Alan Cox 2011-07-12 633
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 634 config X86_INTEL_QUARK
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 635 bool "Intel Quark platform support"
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 636 depends on X86_32
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 637 depends on X86_EXTENDED_PLATFORM
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 638 depends on X86_PLATFORM_DEVICES
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 639 depends on X86_TSC
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 640 depends on PCI
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 641 depends on PCI_GOANY
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 642 depends on X86_IO_APIC
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 643 select IOSF_MBI
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 644 select INTEL_IMR
9ab6eb51ef4ad6 Andy Shevchenko 2015-03-05 645 select COMMON_CLK
a7f7f6248d9740 Masahiro Yamada 2020-06-14 646 help
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 647 Select to include support for Quark X1000 SoC.
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 648 Say Y here if you have a Quark based system such as the Arduino
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 649 compatible Intel Galileo.
8bbc2a135b63be Bryan O'Donoghue 2015-01-30 650
3d48aab1d5035f Mika Westerberg 2013-01-18 651 config X86_INTEL_LPSS
3d48aab1d5035f Mika Westerberg 2013-01-18 652 bool "Intel Low Power Subsystem Support"
5962dd22f0ff6f Sinan Kaya 2019-01-02 653 depends on X86 && ACPI && PCI
3d48aab1d5035f Mika Westerberg 2013-01-18 654 select COMMON_CLK
0f531431d3de88 Mathias Nyman 2013-09-13 655 select PINCTRL
eebb3e8d8aaf28 Andy Shevchenko 2015-12-12 656 select IOSF_MBI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 657 help
3d48aab1d5035f Mika Westerberg 2013-01-18 658 Select to build support for Intel Low Power Subsystem such as
3d48aab1d5035f Mika Westerberg 2013-01-18 659 found on Intel Lynxpoint PCH. Selecting this option enables
0f531431d3de88 Mathias Nyman 2013-09-13 660 things like clock tree (common clock framework) and pincontrol
0f531431d3de88 Mathias Nyman 2013-09-13 661 which are needed by the LPSS peripheral drivers.
3d48aab1d5035f Mika Westerberg 2013-01-18 662
92082a8886f30a Ken Xue 2015-02-06 663 config X86_AMD_PLATFORM_DEVICE
92082a8886f30a Ken Xue 2015-02-06 664 bool "AMD ACPI2Platform devices support"
92082a8886f30a Ken Xue 2015-02-06 665 depends on ACPI
92082a8886f30a Ken Xue 2015-02-06 666 select COMMON_CLK
92082a8886f30a Ken Xue 2015-02-06 667 select PINCTRL
a7f7f6248d9740 Masahiro Yamada 2020-06-14 668 help
92082a8886f30a Ken Xue 2015-02-06 669 Select to interpret AMD specific ACPI device to platform device
92082a8886f30a Ken Xue 2015-02-06 670 such as I2C, UART, GPIO found on AMD Carrizo and later chipsets.
92082a8886f30a Ken Xue 2015-02-06 671 I2C and UART depend on COMMON_CLK to set clock. GPIO driver is
92082a8886f30a Ken Xue 2015-02-06 672 implemented under PINCTRL subsystem.
92082a8886f30a Ken Xue 2015-02-06 673
ced3ce760b8df0 David E. Box 2014-09-17 @674 config IOSF_MBI
ced3ce760b8df0 David E. Box 2014-09-17 675 tristate "Intel SoC IOSF Sideband support for SoC platforms"
ced3ce760b8df0 David E. Box 2014-09-17 676 depends on PCI
a7f7f6248d9740 Masahiro Yamada 2020-06-14 677 help
ced3ce760b8df0 David E. Box 2014-09-17 678 This option enables sideband register access support for Intel SoC
ced3ce760b8df0 David E. Box 2014-09-17 679 platforms. On these platforms the IOSF sideband is used in lieu of
ced3ce760b8df0 David E. Box 2014-09-17 680 MSR's for some register accesses, mostly but not limited to thermal
ced3ce760b8df0 David E. Box 2014-09-17 681 and power. Drivers may query the availability of this device to
ced3ce760b8df0 David E. Box 2014-09-17 682 determine if they need the sideband in order to work on these
ced3ce760b8df0 David E. Box 2014-09-17 683 platforms. The sideband is available on the following SoC products.
ced3ce760b8df0 David E. Box 2014-09-17 684 This list is not meant to be exclusive.
ced3ce760b8df0 David E. Box 2014-09-17 685 - BayTrail
ced3ce760b8df0 David E. Box 2014-09-17 686 - Braswell
ced3ce760b8df0 David E. Box 2014-09-17 687 - Quark
ced3ce760b8df0 David E. Box 2014-09-17 688
ced3ce760b8df0 David E. Box 2014-09-17 689 You should say Y if you are running a kernel on one of these SoC's.
ced3ce760b8df0 David E. Box 2014-09-17 690
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] powercap: intel_rapl: fix CONFIG_IOSF_MBI dependency
@ 2023-06-01 21:32 Arnd Bergmann
2023-06-02 8:04 ` Zhang, Rui
0 siblings, 1 reply; 10+ messages in thread
From: Arnd Bergmann @ 2023-06-01 21:32 UTC (permalink / raw)
To: Rafael J. Wysocki, Zhang Rui
Cc: Arnd Bergmann, Lukasz Luba, Cristian Marussi, Sudeep Holla,
linux-pm, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
When the intel_rapl driver is built-in, but iosf_mbi is a loadable module,
the kernel fails to link:
x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to `iosf_mbi_write'
x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined reference to `iosf_mbi_read'
The driver can work with iosf_mbi completely disabled, so add a dependency
that still allows this configuration, but otherwise forces it to not be
built-in when iosf_mbi is a loadable module.
Fixes: 9eef7f9da928c ("powercap: intel_rapl: Introduce RAPL TPMI interface driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/powercap/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index e71399804c143..21ad50b22d6b9 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -36,6 +36,7 @@ config INTEL_RAPL
config INTEL_RAPL_TPMI
tristate "Intel RAPL Support via TPMI Interface"
depends on X86
+ depends on IOSF_MBI || IOSF_MBI=n
depends on INTEL_TPMI
select INTEL_RAPL_CORE
help
--
2.39.2
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] powercap: intel_rapl: fix CONFIG_IOSF_MBI dependency
2023-06-01 21:32 [PATCH] powercap: intel_rapl: fix " Arnd Bergmann
@ 2023-06-02 8:04 ` Zhang, Rui
2023-06-02 9:11 ` Arnd Bergmann
0 siblings, 1 reply; 10+ messages in thread
From: Zhang, Rui @ 2023-06-02 8:04 UTC (permalink / raw)
To: arnd@kernel.org, rafael@kernel.org
Cc: sudeep.holla@arm.com, lukasz.luba@arm.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
cristian.marussi@arm.com, arnd@arndb.de
Hi, Arnd,
On Thu, 2023-06-01 at 23:32 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When the intel_rapl driver is built-in, but iosf_mbi is a loadable
> module,
> the kernel fails to link:
>
> x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
> intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to
> `iosf_mbi_write'
> x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined
> reference to `iosf_mbi_read'
>
IMO, it is the intel_rapl_common.c that calls IOSF APIs without
specifying the dependency. Thus it should be fixed by something like
below,
From 28de4c7d3d4f9fed75a7ecdcf5eea5b89ed77bab Mon Sep 17 00:00:00 2001
From: Zhang Rui <rui.zhang@intel.com>
Date: Fri, 2 Jun 2023 09:02:15 +0800
Subject: [PATCH] powercap/intel_rapl: Fix CONFIG_IOSF_MBI dependency
After commit 3382388d7148 ("intel_rapl: abstract RAPL common code"),
accessing to IOSF interface is done in the RAPL common code.
Thus it is the CONFIG_INTEL_RAPL_CORE that has dependency of
CONFIG_IOSF_MBI, while CONFIG_INTEL_RAPL_MSR does not.
This problem was not exposed previously because all the previous RAPL
common code users, aka, the RAPL MSR and MMIO I/F drivers, have
CONFIG_IOSF_MBI selected.
Fix the CONFIG_IOSF_MBI dependency in RAPL code. This also fixes a build
time failure when the RAPL TPMI I/F driver is introduced without
selecting CONFIG_IOSF_MBI.
x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to `iosf_mbi_write'
x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined reference to `iosf_mbi_read'
Fixes: 3382388d7148 ("intel_rapl: abstract RAPL common code")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
drivers/powercap/Kconfig | 3 ++-
drivers/powercap/intel_rapl_msr.c | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig
index e71399804c14..adefdd8a4e12 100644
--- a/drivers/powercap/Kconfig
+++ b/drivers/powercap/Kconfig
@@ -18,10 +18,11 @@ if POWERCAP
# Client driver configurations go here.
config INTEL_RAPL_CORE
tristate
+ select IOSF_MBI
config INTEL_RAPL
tristate "Intel RAPL Support via MSR Interface"
- depends on X86 && IOSF_MBI
+ depends on X86
select INTEL_RAPL_CORE
help
This enables support for the Intel Running Average Power Limit (RAPL)
diff --git a/drivers/powercap/intel_rapl_msr.c b/drivers/powercap/intel_rapl_msr.c
index cff5c6e8d570..b536144726f9 100644
--- a/drivers/powercap/intel_rapl_msr.c
+++ b/drivers/powercap/intel_rapl_msr.c
@@ -22,7 +22,6 @@
#include <linux/processor.h>
#include <linux/platform_device.h>
-#include <asm/iosf_mbi.h>
#include <asm/cpu_device_id.h>
#include <asm/intel-family.h>
--
2.25.1
> The driver can work with iosf_mbi completely disabled, so add a
> dependency
> that still allows this configuration, but otherwise forces it to not
> be
> built-in when iosf_mbi is a loadable module.
On the other side, I agree with you that the TPMI driver should work
with iosf_mbi completely disabled.
A cleaner way to do this is to move the rapl_defaults setting (even the
rapl_primitive_info setting) from intel_rapl_common.c to the I/F
drivers, as this is really interface specific.
Maybe we can use the above patch as a quick fix, and remove the
IOSF_MBI dependency from RAPL common code as a long term solution?
thanks,
rui
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH] powercap: intel_rapl: fix CONFIG_IOSF_MBI dependency
2023-06-02 8:04 ` Zhang, Rui
@ 2023-06-02 9:11 ` Arnd Bergmann
2023-06-02 16:55 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Arnd Bergmann @ 2023-06-02 9:11 UTC (permalink / raw)
To: Zhang Rui, Arnd Bergmann, Rafael J . Wysocki
Cc: Sudeep Holla, lukasz.luba@arm.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Cristian Marussi
On Fri, Jun 2, 2023, at 10:04, Zhang, Rui wrote:
> On Thu, 2023-06-01 at 23:32 +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> When the intel_rapl driver is built-in, but iosf_mbi is a loadable
>> module,
>> the kernel fails to link:
>>
>> x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
>> intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to
>> `iosf_mbi_write'
>> x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined
>> reference to `iosf_mbi_read'
>>
>
> IMO, it is the intel_rapl_common.c that calls IOSF APIs without
> specifying the dependency. Thus it should be fixed by something like
> below,
>
> --- a/drivers/powercap/Kconfig
> +++ b/drivers/powercap/Kconfig
> @@ -18,10 +18,11 @@ if POWERCAP
> # Client driver configurations go here.
> config INTEL_RAPL_CORE
> tristate
> + select IOSF_MBI
>
> config INTEL_RAPL
> tristate "Intel RAPL Support via MSR Interface"
> - depends on X86 && IOSF_MBI
> + depends on X86
> select INTEL_RAPL_CORE
> help
> This enables support for the Intel Running Average Power Limit
I think that has the logic slightly backwards from a usability point
of view: The way I read the arch/x86/Kconfig description, IOSF_MBI
is a feature of specific Intel hardware implementations, which
gets enabled when any of these SoC platforms are enabled in
the build, and the INTEL_RAPL driver specifically only works
on those, while the new INTEL_RAPL_TPMI driver works on other
hardware.
More generally speaking, I think it is a mistake for a device
driver in one subsystem to use 'select' to enforce a build
dependency on a driver in another subsystem when the other
symbol is user-visible.
>> The driver can work with iosf_mbi completely disabled, so add a
>> dependency
>> that still allows this configuration, but otherwise forces it to not
>> be
>> built-in when iosf_mbi is a loadable module.
>
> On the other side, I agree with you that the TPMI driver should work
> with iosf_mbi completely disabled.
>
> A cleaner way to do this is to move the rapl_defaults setting (even the
> rapl_primitive_info setting) from intel_rapl_common.c to the I/F
> drivers, as this is really interface specific.
>
> Maybe we can use the above patch as a quick fix, and remove the
> IOSF_MBI dependency from RAPL common code as a long term solution?
I agree that your long-term solution is the best way to avoid the
build dependency, but for the short-term fix I think my patch
makes a little more sense than yours.
Either approach is of course enough to address the build
regression, so no objections to your patch if you still
prefer that.
Arnd
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH] powercap: intel_rapl: fix CONFIG_IOSF_MBI dependency
2023-06-02 9:11 ` Arnd Bergmann
@ 2023-06-02 16:55 ` Rafael J. Wysocki
2023-06-06 12:41 ` Zhang, Rui
0 siblings, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2023-06-02 16:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Zhang Rui, Arnd Bergmann, Rafael J . Wysocki, Sudeep Holla,
lukasz.luba@arm.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, Cristian Marussi
On Fri, Jun 2, 2023 at 11:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Fri, Jun 2, 2023, at 10:04, Zhang, Rui wrote:
> > On Thu, 2023-06-01 at 23:32 +0200, Arnd Bergmann wrote:
> >> From: Arnd Bergmann <arnd@arndb.de>
> >>
> >> When the intel_rapl driver is built-in, but iosf_mbi is a loadable
> >> module,
> >> the kernel fails to link:
> >>
> >> x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
> >> intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to
> >> `iosf_mbi_write'
> >> x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66): undefined
> >> reference to `iosf_mbi_read'
> >>
> >
> > IMO, it is the intel_rapl_common.c that calls IOSF APIs without
> > specifying the dependency. Thus it should be fixed by something like
> > below,
> >
> > --- a/drivers/powercap/Kconfig
> > +++ b/drivers/powercap/Kconfig
> > @@ -18,10 +18,11 @@ if POWERCAP
> > # Client driver configurations go here.
> > config INTEL_RAPL_CORE
> > tristate
> > + select IOSF_MBI
> >
> > config INTEL_RAPL
> > tristate "Intel RAPL Support via MSR Interface"
> > - depends on X86 && IOSF_MBI
> > + depends on X86
> > select INTEL_RAPL_CORE
> > help
> > This enables support for the Intel Running Average Power Limit
>
> I think that has the logic slightly backwards from a usability point
> of view: The way I read the arch/x86/Kconfig description, IOSF_MBI
> is a feature of specific Intel hardware implementations, which
> gets enabled when any of these SoC platforms are enabled in
> the build, and the INTEL_RAPL driver specifically only works
> on those, while the new INTEL_RAPL_TPMI driver works on other
> hardware.
>
> More generally speaking, I think it is a mistake for a device
> driver in one subsystem to use 'select' to enforce a build
> dependency on a driver in another subsystem when the other
> symbol is user-visible.
IOSF_MBI is already selected from multiple places and while you can
argue that they are all mistakes, this particular new one would not be
worse than any of them.
IMO it would be better if IOSF_MBI were not user-visible (and
interestingly enough, whoever selects it should also select PCI or
depend on it - I'm not really sure if that dependency is taken care of
in all cases).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] powercap: intel_rapl: fix CONFIG_IOSF_MBI dependency
2023-06-02 16:55 ` Rafael J. Wysocki
@ 2023-06-06 12:41 ` Zhang, Rui
0 siblings, 0 replies; 10+ messages in thread
From: Zhang, Rui @ 2023-06-06 12:41 UTC (permalink / raw)
To: rafael@kernel.org, arnd@arndb.de
Cc: lukasz.luba@arm.com, linux-pm@vger.kernel.org, arnd@kernel.org,
linux-kernel@vger.kernel.org, sudeep.holla@arm.com,
cristian.marussi@arm.com
Hi, Rafael,
On Fri, 2023-06-02 at 18:55 +0200, Rafael J. Wysocki wrote:
> On Fri, Jun 2, 2023 at 11:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Fri, Jun 2, 2023, at 10:04, Zhang, Rui wrote:
> > > On Thu, 2023-06-01 at 23:32 +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann <arnd@arndb.de>
> > > >
> > > > When the intel_rapl driver is built-in, but iosf_mbi is a
> > > > loadable
> > > > module,
> > > > the kernel fails to link:
> > > >
> > > > x86_64-linux-ld: vmlinux.o: in function `set_floor_freq_atom':
> > > > intel_rapl_common.c:(.text+0x2dac9b8): undefined reference to
> > > > `iosf_mbi_write'
> > > > x86_64-linux-ld: intel_rapl_common.c:(.text+0x2daca66):
> > > > undefined
> > > > reference to `iosf_mbi_read'
> > > >
> > >
> > > IMO, it is the intel_rapl_common.c that calls IOSF APIs without
> > > specifying the dependency. Thus it should be fixed by something
> > > like
> > > below,
> > >
> > > --- a/drivers/powercap/Kconfig
> > > +++ b/drivers/powercap/Kconfig
> > > @@ -18,10 +18,11 @@ if POWERCAP
> > > # Client driver configurations go here.
> > > config INTEL_RAPL_CORE
> > > tristate
> > > + select IOSF_MBI
> > >
> > > config INTEL_RAPL
> > > tristate "Intel RAPL Support via MSR Interface"
> > > - depends on X86 && IOSF_MBI
> > > + depends on X86
> > > select INTEL_RAPL_CORE
> > > help
> > > This enables support for the Intel Running Average Power
> > > Limit
> >
> > I think that has the logic slightly backwards from a usability
> > point
> > of view: The way I read the arch/x86/Kconfig description, IOSF_MBI
> > is a feature of specific Intel hardware implementations, which
> > gets enabled when any of these SoC platforms are enabled in
> > the build, and the INTEL_RAPL driver specifically only works
> > on those, while the new INTEL_RAPL_TPMI driver works on other
> > hardware.
> >
> > More generally speaking, I think it is a mistake for a device
> > driver in one subsystem to use 'select' to enforce a build
> > dependency on a driver in another subsystem when the other
> > symbol is user-visible.
>
> IOSF_MBI is already selected from multiple places and while you can
> argue that they are all mistakes, this particular new one would not
> be
> worse than any of them.
>
> IMO it would be better if IOSF_MBI were not user-visible (and
> interestingly enough, whoever selects it should also select PCI or
> depend on it - I'm not really sure if that dependency is taken care
> of
> in all cases).
Agreed.
Even the previous RAPL code does not select PCI or depend on it.
Let me refresh the patch and resend.
thanks,
rui
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-06-12 17:50 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-06-06 14:00 [PATCH] powercap: intel_rapl: Fix CONFIG_IOSF_MBI dependency Zhang Rui
2023-06-06 15:45 ` kernel test robot
2023-06-07 2:22 ` Zhang, Rui
2023-06-12 17:50 ` Rafael J. Wysocki
2023-06-06 16:17 ` kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2023-06-01 21:32 [PATCH] powercap: intel_rapl: fix " Arnd Bergmann
2023-06-02 8:04 ` Zhang, Rui
2023-06-02 9:11 ` Arnd Bergmann
2023-06-02 16:55 ` Rafael J. Wysocki
2023-06-06 12:41 ` Zhang, Rui
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).