CHROMIUM: Align x86 config flavours

CHROMIUM: Align x86 config flavours

To make a good starting point for kernel config hardening (which will
modify i386 ChromeOS config but leave ChromiumOS config unchanged),
empty out chromeos-pinetrail-i386 and chromiumos-i386 config flavours.

Make CONFIG_BROADCOM_PHY=y in all ChromeOS i386 and x86_64 configs:
it was turned on for Chromium on some non-Chrome devices, does no harm
to Chrome than enlarge its kernel, we'll "harden" it out again after.

Make CONFIG_DRM_I915_DIRECT_BACKLIGHT=y in i386 ChromiumOS config:
it was turned on in the rest of x86, and does not harm to Chromium.

Make CONFIG_PRESERVED_RAM=y in i386 ChromiumOS and x86_64 configs:
a commit has now gone into the tree to make it safe on Chromium.
x86_64 needed CONFIG_CHROME=y and CONFIG_ACPI_CHROMEOS=y too
(but I've not built or tested the x86_64 kernel).

CONFIG_ARCH_CPU_PROBE_RELEASE=y and CONFIG_MAC80211_HAS_RC=y come
in from running editconfig on a newer tree than it was last run.

BUG=chromium-os:4834
TEST=build and run

Change-Id: I228bcd8e91dd9521545d449d0f59e1cce3b3ecf7
Signed-off-by: Hugh Dickins <hughd@chromium.org>;

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=fb44ef1

[hughd, 2010-10-11 02:38:02]

Not sure if it was my mistake or splitconfig's, but I've just found that
CONFIG_MAC80211_HAS_RC=y now moves up to config.common.chromeos.

And I've also found that despite the "New Workflow" doc saying "Note: If you
want to start a new branch while waiting on a CL review, use repo start to
create it instead of git.  This ensures that the proper tracking branch is
created.", when I try that from the branch with thos CL in, I get a branch
without this in: which fills me with dread.

Sorry guys, I'm going to "git cl push" this right away, TBR.

[Olof Johansson, 2010-10-11 14:28:52]

On Sun, Oct 10, 2010 at 7:38 PM, <hughd@chromium.org> wrote:

> Not sure if it was my mistake or splitconfig's, but I've just found that
> CONFIG_MAC80211_HAS_RC=y now moves up to config.common.chromeos.
>
> And I've also found that despite the "New Workflow" doc saying "Note: If
> you
> want to start a new branch while waiting on a CL review, use repo start to
> create it instead of git.  This ensures that the proper tracking branch is
> created.", when I try that from the branch with thos CL in, I get a branch
> without this in: which fills me with dread.
>

That's behaving as expected. The note is meant for independent changes, and
the new branch should not have the previous change in it since it was not
part of the upstream tree at the time of repo start.


-Olof

[kliegs, 2010-10-12 15:24:48]

Please don't just TBR changes like this.  While these are relatively minor
changes, pushing out kernel changes on the weekend without a review has the
potential to cost a lot of time.  Unless the change is an emergency one
fixing something that's broken and affecting multiple people, rushing code
out isn't effective in the long term.

If you have trouble or confusion around the tools then feel free to ask for
clarification on them, file bugs for the missing features or give feedback
on how to fix them.  It took me some time to adjust to using repo, but its
the tools we're using so we need to make sure we use it properly.

-Jon


On Mon, Oct 11, 2010 at 10:28 AM, Olof Johansson <olofj@chromium.org> wrote:

>
>
> On Sun, Oct 10, 2010 at 7:38 PM, <hughd@chromium.org> wrote:
>
>> Not sure if it was my mistake or splitconfig's, but I've just found that
>> CONFIG_MAC80211_HAS_RC=y now moves up to config.common.chromeos.
>>
>> And I've also found that despite the "New Workflow" doc saying "Note: If
>> you
>> want to start a new branch while waiting on a CL review, use repo start to
>> create it instead of git.  This ensures that the proper tracking branch is
>> created.", when I try that from the branch with thos CL in, I get a branch
>> without this in: which fills me with dread.
>>
>
> That's behaving as expected. The note is meant for independent changes, and
> the new branch should not have the previous change in it since it was not
> part of the upstream tree at the time of repo start.
>
>
> -Olof
>
>