From: Patrick Williams <patrick@stwcx.xyz>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
Iwona Winiarska <iwona.winiarska@intel.com>,
openbmc@lists.ozlabs.org,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Joel Stanley <joel@jms.id.au>,
Jason M Bills <jason.m.bills@linux.intel.com>
Subject: Re: [PATCH] peci: PECI should depend on ARCH_ASPEED
Date: Tue, 29 Mar 2022 12:08:24 -0500 [thread overview]
Message-ID: <YkM9CPbeARpWHMPw@heinlein> (raw)
In-Reply-To: <YkLgapMN2JqM+Lte@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Tue, Mar 29, 2022 at 12:33:14PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 29, 2022 at 11:21:37AM +0200, Geert Uytterhoeven wrote:
> > The Platform Environment Control Interface (PECI) is only available on
> > Baseboard Management Controllers (BMC) for Intel processors. Currently
> > the only supported BMCs are ASpeed BMC SoCs. Hence add a dependency on
> > ARCH_ASPEED, to prevent asking the user about the PECI subsystem when
> > configuring a kernel without ASpeed SoC support.
> >
> > Fixes: 6523d3b2ffa238ac ("peci: Add core infrastructure")
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > drivers/peci/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/peci/Kconfig b/drivers/peci/Kconfig
> > index 89872ad833201510..0d3ef8ba0998d649 100644
> > --- a/drivers/peci/Kconfig
> > +++ b/drivers/peci/Kconfig
> > @@ -2,6 +2,7 @@
> >
> > menuconfig PECI
> > tristate "PECI support"
> > + depends on ARCH_ASPEED || COMPILE_TEST
>
> I hate ARCH_ dependencies as there is nothing specific with that one
> platform that means that this driver subsystem will only work on that
> one.
The motivation in the commit message isn't even accurate because the chips
under ARCH_NPCM are usually used as a BMC as well and PECI is just as important
for them. HPE also has a custom chip they use as BMC and they've started the
process for upstreaming that support.
> I'm all for fixing build dependancies, but it should be fine to build
> all drivers for all arches.
There are a few drivers, like PECI and FSI, that are likely only useful
when being used in the BMC space. Is it worth having a "config BMC" for
drivers which are likely only useful in a BMC environment and that we can
"if BMC" around these drivers so they get hidden from the menuconfig for
typical use cases?
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Williams <patrick@stwcx.xyz>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
Iwona Winiarska <iwona.winiarska@intel.com>,
openbmc@lists.ozlabs.org,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
linux-kernel@vger.kernel.org, Joel Stanley <joel@jms.id.au>,
Jason M Bills <jason.m.bills@linux.intel.com>
Subject: Re: [PATCH] peci: PECI should depend on ARCH_ASPEED
Date: Tue, 29 Mar 2022 12:08:24 -0500 [thread overview]
Message-ID: <YkM9CPbeARpWHMPw@heinlein> (raw)
In-Reply-To: <YkLgapMN2JqM+Lte@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Tue, Mar 29, 2022 at 12:33:14PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 29, 2022 at 11:21:37AM +0200, Geert Uytterhoeven wrote:
> > The Platform Environment Control Interface (PECI) is only available on
> > Baseboard Management Controllers (BMC) for Intel processors. Currently
> > the only supported BMCs are ASpeed BMC SoCs. Hence add a dependency on
> > ARCH_ASPEED, to prevent asking the user about the PECI subsystem when
> > configuring a kernel without ASpeed SoC support.
> >
> > Fixes: 6523d3b2ffa238ac ("peci: Add core infrastructure")
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > drivers/peci/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/peci/Kconfig b/drivers/peci/Kconfig
> > index 89872ad833201510..0d3ef8ba0998d649 100644
> > --- a/drivers/peci/Kconfig
> > +++ b/drivers/peci/Kconfig
> > @@ -2,6 +2,7 @@
> >
> > menuconfig PECI
> > tristate "PECI support"
> > + depends on ARCH_ASPEED || COMPILE_TEST
>
> I hate ARCH_ dependencies as there is nothing specific with that one
> platform that means that this driver subsystem will only work on that
> one.
The motivation in the commit message isn't even accurate because the chips
under ARCH_NPCM are usually used as a BMC as well and PECI is just as important
for them. HPE also has a custom chip they use as BMC and they've started the
process for upstreaming that support.
> I'm all for fixing build dependancies, but it should be fine to build
> all drivers for all arches.
There are a few drivers, like PECI and FSI, that are likely only useful
when being used in the BMC space. Is it worth having a "config BMC" for
drivers which are likely only useful in a BMC environment and that we can
"if BMC" around these drivers so they get hidden from the menuconfig for
typical use cases?
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-03-29 17:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 9:21 [PATCH] peci: PECI should depend on ARCH_ASPEED Geert Uytterhoeven
2022-03-29 9:21 ` Geert Uytterhoeven
2022-03-29 10:33 ` Greg Kroah-Hartman
2022-03-29 10:33 ` Greg Kroah-Hartman
2022-03-29 17:08 ` Patrick Williams [this message]
2022-03-29 17:08 ` Patrick Williams
2022-03-30 10:37 ` Winiarska, Iwona
2022-03-30 10:37 ` Winiarska, Iwona
2022-03-30 11:51 ` Geert Uytterhoeven
2022-03-30 11:51 ` Geert Uytterhoeven
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=YkM9CPbeARpWHMPw@heinlein \
--to=patrick@stwcx.xyz \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=iwona.winiarska@intel.com \
--cc=jae.hyun.yoo@linux.intel.com \
--cc=jason.m.bills@linux.intel.com \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=pierre-louis.bossart@linux.intel.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.