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 <thuth@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 <thuth@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.