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

Bruce Ashfield bruce.ashfield at windriver.com
Mon Jul 6 09:42:43 PDT 2015


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



More information about the linux-yocto mailing list