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

[Bruce Ashfield]

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.

Bruce

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