| Age | Commit message (Collapse) | Author |
|---|
|
The kernel configuration audit subsystem was previously focussed on
BSP/hardware specific options, since that is the part of configuration
that the end developer maintains.
But not auditing the non-hardware specific options on each run meant
that some options that do not exist in the kernel have remained in the
configuration fragments.
Removing them clarifies the fragments, and updating the audit to report
on non-hardware options ensures that they will stay clean.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
|
|
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Enable virtio-console by default when virtio is requested by a BSP.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The ipv6 support is no longer the experimental/academic project
that it was many years ago. People expect it to be there as
part of basic support. So make it built in, by aligning with
the current kernel.org defconfig.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Since there is no need for them to differ on something that
is not going to be impacted by RT patches.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
There is no reason for RT and standard to have their own personal
copies of bridge netfilter settings. Make them source a common file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
There is no reason for RT and standard to have their own personal
copies of IPv6 netfilter settings. Make them source a common file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
There is no reason for RT and standard to have their own personal
copies of IPv4 netfilter settings. Make them source a common file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
So that it is alongside the other fs related content.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
These are the defaults for x86 and x86_64 when doing a defconfig
on those arch with the kernel.org tree. Ours might as well be
the same values.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
If we are in the cfg dir already, we don't need a leading
cfg prefix on the paths.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This seems like a logical grouping to reduce the cluster
accumulation in cfg for another while.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Things are starting to get a bit busy in the cfg dir. We may
not want to mirror every kernel path on a 1:1 basis, but at
least having a fs dir for filesystem cruft makes sense.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
In mainline defconfigs we have:
arch/x86/configs/i386_defconfig:# CONFIG_MTRR_SANITIZER is not set
arch/x86/configs/x86_64_defconfig:# CONFIG_MTRR_SANITIZER is not set
But the defaults given by the Kconfig stanza are "def_bool y" so
if we want to match the defconfigs, we need to call it out as off
explicitly.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The efi.cfg calls out EFI and ACPI settings. Make sure it is in
both x86 and x86_64, and then delete all x86/x86_64 BSP specific
references directly to the efi.scc
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This matches the upstream defconfig settings for each of
x86 and x86_64 respectively in kernel.org 3.4 tree.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
This is in keeping with the upstream defconfigs
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The default x86[64] defconfig on a kernel.org 3.4 tree will have these
enabled. Since we can't be sure we'll be running on a platform
with or without these issues, it makes sense for us to have them
enabled here as well.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Currently, BSPs like common-pc differ from the korg x86 defconfig
as follows:
common_pc x86 korg defconfig
------------------------------------------------------------------
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not set
# CONFIG_HIGHPTE is not set CONFIG_HIGHPTE=y
Given that machines with 4G or more RAM are nothing at all unique
anymore, lets align ourselves with enabling HIGHPTE.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Comparing a common-pc config to kernel.org x86 defconfig
reveals this difference:
--- common-pc --- --- korg defconfig ---
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
# CONFIG_X86_REBOOTFIXUPS is not set CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_AMD=y
Align the x86 defaults with what is in kernel.org, since we've no
real justification for not doing so.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
You are hard pressed to find a true single core x86 chip now,
even those which are a single core typically have hyperthread,
and so we'd want SMP+SCHED_SMT from the smp config frag anyway.
Delete the now redundant include from the existing BSPs too.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
It is on by default for 64bit x86 and only optional if you
are x86 32 bit. Ensure it is on for the latter so we are
aligned with the kernel.org x86 defconfig.
This was listed as a feature, but since HPET has been around
for a while now, we'll not likely be carrying extra patches
for HPET as per the other features.
By sticking it in the shared x86 and x86_64 frags, we can
delete BSP specific mentions of it.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
At the moment, there are no 8250 patches applied, however
if there were, we'd run into issues where they were not
applied at the standard (pre-bsp) level, but instead applied
once per each BSP, duplicating content with unique commit IDs.
Separate out the 8250 enablement Kconfig settings to a cfg
frag, and ensure that the feature [which may someday optionally
contain patches] gets processed independent of the BSPs.
The BSPs which were asking for the feature now just ask for
the enabling config frag in cfg dir.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
There will be a significant amount of cfg data that is common
across all x86 BSPs. Make a landing ground for it here, similar
to what ARM has, so that we don't duplicate a bunch of stuff
in every x86 BSP file.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
I've skipped HZ=300 because in all kernel defconfigs, it is
only ever referenced by one blackfin board.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Configuration is unchanged. It just makes ext2 settings the
same mechanism as ext3 and ext4.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Remove the SCSI and BLK_DEV_SD options from usb-mass-storage.cfg and
replace them with the corresponding scsi/ features.
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
The config fragments in the tiny ktype were simply pulled in
from a collection of experimental fragments. Boil things down
to a core policy (yocto.cfg) and tiny-specific configs (tiny.cfg).
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Several BSPs duplicated the boot-live fragment in their BSP
specific config. Remove the duplication and add CONFIG_RD_GZIP
and CONFIG_BLK_DEV_SR to the boot-live fragment.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Acked-by: Tom Zanussi <tzanussi@intel.com>
|
|
For targets with the appropriate hardware support, they should include
this option to enable the appropriate kernel features.
Signed-off-by: Kishore Bodke <kishore.k.bodke@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Basic EFI support only requires CONFIG_EFI=y, this is sufficient for
some boards, and desirable for small configs. This is done with efi.scc.
Additional support for CONFIG_EFI_VARS, CONFIG_EFI_PARTITION, and CONFIG_FB_EFI
is provided via efi-ext.scc (extended) as this pulls in the block layer,
framebuffer support, and virtual terminals.
I'd like EFI_VARS to be part of the base config, but I have received
reports of it failing in some situations. Keeping it separate ensures
basic boot can work with the fragments as defined.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
Adding CONFIG_ISO9660_FS=y in boot-live.cfg to enable live booting.
Move boot-live.cfg from bsp/atom-pc to cfg/ and add boot-live.scc.
Signed-off-by: Jingdong Lu <jingdong.lu@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
For reusable BSPs like atom-pc which may or may not have SMP support,
allow the linux-yocto recipe to choose whether or not to enable SMP support.
The smp config fragment enables SMP and SCHED_SMT.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
cfg/vfat.cfg did not have an associated .scc file, which meant
that it could not be included by features and command line
options.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
Roughly corresponds to:
commit db575247e16e50ce5160e18907e253c6a43b6feb
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Mon Apr 4 00:27:55 2011 -0400
yocto: 2.6.39 baseline
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
...in the full history repo, but with some extraneous files that were
deleted post db575247 deleted right here and now at the baseline
instead.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
Bruce Ashfield
Cristian Iorga
Paul Gortmaker
Tom Zanussi
Darren Hart
Darren Hart
Kishore Bodke
Jingdong Lu
Nitin A Kamble