On 09/28/2016 04:04 PM, Alejandro Hernandez wrote:
On 09/28/2016 01:45 PM, Bruce Ashfield wrote:
On 09/27/2016 12:48 PM, Alejandro Hernandez wrote:
Signed-off-by: Alejandro Hernandez <alejandro.hernan...@linux.intel.com>
---
bsp/common-pc-64/common-pc-64.scc | 1 +
1 file changed, 1 insertion(+)
diff --git a/bsp/common-pc-64/common-pc-64.scc
b/bsp/common-pc-64/common-pc-64.scc
index 5737a83..f5a3076 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -10,6 +10,7 @@ include cfg/x86_64.scc
include cfg/amd.scc
include cfg/intel.scc
include features/pci/pci.scc
+include features/mmc/mmc-sdhci.scc
Rather than including this here, and inflicting the extra build/modules
on everyone that uses the common-pc baseline, wouldn't it be better if
the BSPs that need this support included it directly ?
On that topic, what sorts of platforms and use cases need this ? If it
is a broad set of platforms, then adding it in common-pc makes sense ..
Bruce
I agree, in this case genericx86 and genericx86-64 should include mmc
support, is there a better place to add this for this scenario?
Hmmm. That is the problem, genericx86* map directly to common-pc, so
they are fundamentally the same thing.
The only way to make it optional for boards like that is to use
KERNEL_FEATURES_genericx86_append .. and then list the features.
But we don't necessarily have to go that way, if we just cover what
mmc devices are being used, and what use case they are covering
(i.e. are these common parts that are being used for storage ?
boot ? .. something else ?).
Since as I said, if they are common and the use case is valid, we
can just turn them on in common-pc.
Bruce
Alejandro
include features/usb/ehci-hcd.scc
include features/usb/uhci-hcd.scc
include features/usb/ohci-hcd.scc
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
