[linux-yocto] [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family

[Paul Gortmaker]

[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.

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.

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.  :)

P.
--

> 
> let's touch base about this tomorrow morning.
> 
> Sau!
> 
> 
> 
> >Bruce
> >
> >>
> >>>Signed-off-by: Saul Wold <sgw at 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
> >>>
> >>
> >