On 2015-07-06 12:16 PM, Saul Wold wrote:
On 07/06/2015 07:18 AM, Bruce Ashfield wrote:
On 2015-07-06 9:55 AM, Paul Gortmaker wrote:
[Re: [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet
controller family] On 05/07/2015 (Sun 22:30) Saul Wold wrote:
On 07/05/2015 08:52 PM, Bruce Ashfield wrote:
On 2015-07-01 7:15 PM, Darren Hart wrote:
On 7/1/15 4:06 PM, Saul Wold wrote:
This is needed for the meta-quark BSP which is used by the Galileo
Board.
Still would like to see this in features/net - or some discussion
as to
why not.
Agreed. We can start a cleanup of the net* fragments with a
small bit of effort here. A good example for any following
SOCs.
I have updated my branch linux-yocto-contrib/sgw/refactor-wip with
this change along with the rest of the refactoring of the x86/x86_64
and x86_base changes.
One of the key differences is the way we handle MTRR_SANITIZER, by
removing the not set as Darren recommended we get the following
difference:
< # CONFIG_MTRR_SANITIZER is not set
---
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
Paul G was the person that added the not set to have it match the
kernel.org defconfig for x86/x86_64. Since the default is disabled
is there any reason to continue explicitly saying not set?
There are a couple reasons I typically do sth. like that. One is that
it makes it explicitly clear that it was a choice and not just a "lets
go with the default", even if in this case the underlying reason was
to get better alignment with the defconfig (which is _not_ the same as
taking the defaults for everything).
Another reason, is that if the default changes, you won't just get swept
along for the ride without knowing what happened. You will stay where
you were until you decide whether you consciously want to align with the
new default.
I'm also a fan of not relying on defaults for configs we care about
(as we all know, we don't set them all) for the same reasons paul
highlights.
And finally, (assuming that this is set at a higher level) you will get
a warning from the config audit about the divergence from the more
global value if a later level (in config prio) BSP decides to change it.
Yep, and even if something selects it (to change our default), we'll get
a log in the configuration audit.
Of course none of these are critical, and if we have a lot of BSPs that
want it on, then the explicit "not set" may not make sense anymore and
hence rolling back to accepting the default to make BSP life easier may
be the right thing to do; I don't have enough context to know, given
that I just got dragged into this discussion now. :)
Agreed as well.
We all got "dragged" into this as I started the refactor and Darren
asked the questions. I looked at the Kconfig description for
MTRR_SANITIZER and related and it seems safe to enable it as default.
Bruce, do you want me include or exclude the MTRR_SANITIZER in a v4?
Let's try it as a default to 'on' for the x86 platforms.
Bruce
Sau!
Bruce
P.
--
let's touch base about this tomorrow morning.
Sau!
Bruce
Signed-off-by: Saul Wold <s...@linux.intel.com>
---
meta/cfg/kernel-cache/features/stmicro/stmmac.cfg | 6 ++++++
meta/cfg/kernel-cache/features/stmicro/stmmac.scc | 2 ++
2 files changed, 8 insertions(+)
create mode 100644
meta/cfg/kernel-cache/features/stmicro/stmmac.cfg
create mode 100644
meta/cfg/kernel-cache/features/stmicro/stmmac.scc
diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg
b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg
new file mode 100644
index 0000000..63e06d61
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg
@@ -0,0 +1,6 @@
+CONFIG_NET_CORE=y
+CONFIG_ETHERNET=y
+CONFIG_NET_VENDOR_STMICRO=y
+CONFIG_STMMAC_ETH=y
+CONFIG_STMMAC_PLATFORM=y
+CONFIG_STMMAC_PCI=y
diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.scc
b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc
new file mode 100644
index 0000000..7951713b
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc
@@ -0,0 +1,2 @@
+
+kconf hardware stmmac.cfg
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
