On Tue, Dec 3, 2019 at 4:38 AM Xu, Yanfei <yanfei...@windriver.com> wrote: > > > On 12/2/19 12:28 PM, Bruce Ashfield wrote: > > In message: [linux-yocto][yocto-kernel-cache master/yocto-5.2][PATCH] > features: avoid enabling edac feature in mips > on 27/11/2019 yanfei...@windriver.com wrote: > > From: Yanfei Xu <yanfei...@windriver.com> > > When some layer include this edac feature and bitbake kernel ARCH > =mips, that will cause some warning masseges. > > CONFIG_EDAC and CONFIG_EDAC_DEBUG depend on CONFIG_EDAC_SUPPORT, > but CONFIG_EDAC_SUPPORT isn't enabled in most of mips bsps(except > CAVIUM_OCTEON_SOC, however CAVIUM_OCTEON_SOC is not defined in > bsps) > > Signed-off-by: Yanfei Xu <yanfei...@windriver.com> > --- > features/edac/edac-enable.scc | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/features/edac/edac-enable.scc b/features/edac/edac-enable.scc > index c60d2790..f9a56af0 100644 > --- a/features/edac/edac-enable.scc > +++ b/features/edac/edac-enable.scc > @@ -1,5 +1,7 @@ > # SPDX-License-Identifier: MIT > -define KFEATURE_DESCRIPTION "Enable core EDAC functionality" > -define KFEATURE_COMPATIBILITY board > +if [ "$KARCH" != "mips" ]; then > + define KFEATURE_DESCRIPTION "Enable core EDAC functionality" > + define KFEATURE_COMPATIBILITY board > > We should leave the feature descriptions outside of the if statement. > > Yes, you are right. > > That being said, this fragment isn't included directly by any of the common > features/kernel types or other fragments. > > We already have the compatibility tagged as "board", so really, only boards > with the right hardware should be including this fragment. Which leads me > to this question: how is this feature being included by those mips boards ? > Is it via KERNEL_FEATURES or some other mechanism ? > > We include this feature via KERNEL_FEATURES. > > I have a qestion about KFEATURE_COMPATIBILITY. Is this tag only a prompt for > user when using the features that contained KFEATURE_COMPATIBILITY? (Because I > didn't find any file that parses it.) > If that, I am agree with you that we should do an exclude on layers with > referencing KFEATURE_COMPATIBILITY.
There are (old) tools that used to use the values in those variables to present kernel configuration options to a developer. We could start using them again in a more direct way, but as they currently stand they are mostly documentation and a reference in the kernel configuration meta-data. So I'm good with these being fixed in two places, both in the meta-data with the if based exclusion and also in the boards using a architecture based bitbake OVERRIDE variable to not include the feature for mips boards. Bruce > > Yanfei > > The reason I ask, is that we should probably do an architecture level > exclude on those boards/layers versus adding an if statement to the > feature fragment (or best case, it should be done in both places). > > Bruce > > > -kconf hardware edac.cfg > + kconf hardware edac.cfg > +fi > -- > 2.23.0 > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#8173): https://lists.yoctoproject.org/g/linux-yocto/message/8173 Mute This Topic: https://lists.yoctoproject.org/mt/63635414/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
