On 2/15/19 1:15 PM, Thomas Huth wrote: > On 14/02/2019 21.35, Paolo Bonzini wrote: >> On 14/02/19 20:17, Peter Maydell wrote: >>> On Wed, 13 Feb 2019 at 08:38, Thomas Huth <th...@redhat.com> wrote: >>>> >>>> Add Kconfig dependencies for the highbank machine (and the midway >>>> machine). >>>> This patch is slightly based on earlier work by Ákos Kovács (i.e. >>>> his "hw/arm/Kconfig: Add ARM Kconfig" patch). >>>> >>>> Signed-off-by: Thomas Huth <th...@redhat.com> >>>> --- >>>> default-configs/arm-softmmu.mak | 4 +--- >>>> hw/arm/Kconfig | 12 ++++++++++++ >>>> 2 files changed, 13 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/default-configs/arm-softmmu.mak >>>> b/default-configs/arm-softmmu.mak >>>> index 3baafc4..59734ee 100644 >>>> --- a/default-configs/arm-softmmu.mak >>>> +++ b/default-configs/arm-softmmu.mak >>>> @@ -6,6 +6,7 @@ CONFIG_ARM_V7M=y >>>> CONFIG_PCI_DEVICES=y >>>> >>>> CONFIG_EXYNOS4=y >>>> +CONFIG_HIGHBANK=y >>>> >>>> CONFIG_VGA=y >>>> CONFIG_NAND=y >>>> @@ -54,14 +55,12 @@ CONFIG_PL022=y >>>> CONFIG_PL031=y >>>> CONFIG_PL041=y >>>> CONFIG_PL050=y >>>> -CONFIG_PL061=y >>>> CONFIG_PL080=y >>>> CONFIG_PL110=y >>>> CONFIG_PL181=y >>>> CONFIG_PL190=y >>>> CONFIG_PL330=y >>>> CONFIG_CADENCE=y >>>> -CONFIG_XGMAC=y >>> >>> Could you explain the logic for when CONFIG_*=y >>> lines get deleted from the arm-softmmu.mak? >>> In this patch PL061 has been deleted, but PL011, >>> PL022, PL031 have not, though all these devices are >>> used in both Highbank and in other not-yet-converted >>> machine types. What's the difference ? > > My plan was indeed to remove the switches from the default-configs file > as soon as they are enabled in the Kconfig file. Looks like I missed > these here in this patch, sorry! > > (but unless there are other reasons for respinning, I think it should > also be OK if the switches get removed in later patches instead) > >> I think it's a mistake. I'd not remove any CONFIG_*=y except in a final >> separate patch. > > Really? In that case it's way harder to see which options from the > default-configs are really handled in the Kconfig files - and there's a > risk that some options would get removed that are not enabled in any of > the preceeding Kconfig patches. So I think it's better this way, bit by bit.
Agreed. This way you can build/test at each step.
