[linux-yocto] [PATCH 07/10] stmicro: Add support for the STMMAC Ethernet controller family

[Bruce Ashfield]

On 2015-07-01 1:43 PM, Darren Hart wrote:
> On 7/1/15 9:57 AM, Saul Wold wrote:
>> This is needed for the x1000 SOC platform
>
> This is on the SoC itself? Not an additional chip on the board?
>
>> 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
>
>
> Taking a closer look at the current set of features, they are mostly
> topical, rather than vendor. I'm surprised to find we don't have a "net"
> in there yet. We do have "net" in cfg (rather than features), but that's
> more about protocols than drivers (inexplicably so).
>
> In my opinion, this would be better organized as:
>
> features/
>    net/
>      net.scc
>      net.cfg
>      net-all.scc
>      stmicro/
>        stmmac.scc (includes net.cfg)
>        stmmac.cfg
>
> Similar to the features/media setup.
>
> Bruce, any preference? I think we need a couple of READMEs in the

No strong preference. The current structure has been needs driven
and gets refactored as new fragments and use cases are added.

No objection to the above proposal. With the only caution that I'd
prefer to not get too deep in the directory structure, or have really
small fragments. But we can cross that bridge if we get there.

> kernel-cache hierarchy (cfg, features, ktype, etc. to help guide folks

I swear we created something like this before .. but I can't find it at
the moment.

This is a good idea, what about a low priority bugilla case ? .. something
I can handle in the later sprints for the fall release.

> creating fragments). I would suggest following the Kconfig hierarchy as
> much as possible to avoid confusion.

Agreed .. while keeping the depth reasonable.

Bruce

>