From: Trevor Woerner <trevor@toganlabs.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1 4/5] CONFIG_SYS_[DI]CACHE_OFF: convert to Kconfig
Date: Thu, 18 Apr 2019 16:51:58 -0400 [thread overview]
Message-ID: <20190418205157.GA24770@linux-uys3> (raw)
In-Reply-To: <CY4PR1201MB01201EBC9CD16BEF011935A9A1260@CY4PR1201MB0120.namprd12.prod.outlook.com>
On Thu 2019-04-18 @ 04:49:30 PM, Alexey Brodkin wrote:
> Hi Trevor,
>
> > -----Original Message-----
>
> > CONFIG_SYS_[DI]CACHE_OFF had been partially converted to Kconfig
> > parameters; only for the ARC architecture. This patch turns these two
> > parameters into Kconfig items everywhere else they are found.
> >
> > All of the include/configs/* and defconfig changes in this patch are
> > for arm machines only. The Kconfig changes for arc, nds32, riscv,
> > and xtensa have been included since these symbols are found in code
> > under arch/{arc,nds32,riscv,xtensa}, however, no currently-defined
> > include/configs/* or defconfigs for these architectures exist which
> > include these symbols.
> >
> > These results have been confirmed with tools/moveconfig.py.
> >
> > Signed-off-by: Trevor Woerner <trevor@toganlabs.com>
> >
> > ---
> >
> > README | 2 --
> > arch/arc/Kconfig | 8 ++++++--
>
> Even though I'm ok with ARC changes (which are just
> rephrases in help message) I'm wondering if we now may finally
> move both items (for D$ & I$) to a higher level to reduce duplication?
>
> Acked-by: Alexey Brodkin <abrodkin@snopsys.com>
Hi Alexey,
Thank you for your review!
The changes I made to the ARC menu were just to make all the text the same
between all the architectures.
Regarding moving the cache configuration up to a higher level, I had asked
myself the same question as I prepared these patches.
I wouldn't want people to think they have have the ability to affect
whether of not the caches are enabled on architectures where no such
ability is possible in the code. So I either had to enable it on a
per-architecture basis, or I would have to add "depends on ARC || ARM ||
..." if I moved it to a higher level.
In my first pass through this change, I had done exactly that. I had moved
these options out from ARC and put them at a higher level with a "depends
on ..." clause. However I wasn't happy with the result, because, to me, I
would rather be asked questions about enabling caches in the
architecture-specific menus, rather than at a higher-level "general" menu.
Does that seem like a good idea? Does it make more sense to ask people
questions about the cache in an architecture-specific menu rather than in a
general or higher-level menu?
Best regards,
Trevor
next prev parent reply other threads:[~2019-04-18 20:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-18 13:11 [U-Boot] [PATCH v1 0/5] Kconfig conversion: CONFIG_SYS_[DI]CACHE_OFF Trevor Woerner
2019-04-18 13:11 ` [U-Boot] [PATCH v1 1/5] CONFIG_SYS_[ID]CACHE_OFF: unify the 'any' case Trevor Woerner
2019-04-18 13:11 ` [U-Boot] [PATCH v1 2/5] CONFIG_SYS_[DI]CACHE_OFF: remove superfluous "1" Trevor Woerner
2019-04-18 13:11 ` [U-Boot] [PATCH v1 3/5] CONFIG_SYS_[DI]CACHE_OFF: remove commented lines Trevor Woerner
2019-04-18 13:11 ` [U-Boot] [PATCH v1 4/5] CONFIG_SYS_[DI]CACHE_OFF: convert to Kconfig Trevor Woerner
2019-04-18 16:49 ` Alexey Brodkin
2019-04-18 20:51 ` Trevor Woerner [this message]
2019-04-18 13:11 ` [U-Boot] [PATCH v1 5/5] CONFIG_SPL_SYS_[DI]CACHE_OFF: add Trevor Woerner
2019-04-18 16:43 ` Alexey Brodkin
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=20190418205157.GA24770@linux-uys3 \
--to=trevor@toganlabs.com \
--cc=u-boot@lists.denx.de \
/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.