On 14/05/2019 12.25, Philippe Mathieu-Daudé wrote: > On 5/14/19 12:06 PM, Peter Maydell wrote: >> On Tue, 14 May 2019 at 11:00, Thomas Huth <th...@redhat.com> wrote: >>> >>> The "or-irq" device is only used by certain machines. Let's add >>> a proper config switch for it so that it only gets compiled when we >>> really need it. >>> >>> Signed-off-by: Thomas Huth <th...@redhat.com> >>> --- >>> hw/arm/Kconfig | 2 ++ >>> hw/core/Kconfig | 3 +++ >>> hw/core/Makefile.objs | 2 +- >>> hw/pci-host/Kconfig | 3 ++- >>> 4 files changed, 8 insertions(+), 2 deletions(-) >>> >>> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig >>> index af8cffde9c..0bb3bbe9d3 100644 >>> --- a/hw/arm/Kconfig >>> +++ b/hw/arm/Kconfig >>> @@ -277,6 +277,7 @@ config RASPI >>> config STM32F205_SOC >>> bool >>> select ARM_V7M >>> + select OR_IRQ >>> select STM32F2XX_TIMER >>> select STM32F2XX_USART >>> select STM32F2XX_SYSCFG >>> @@ -424,6 +425,7 @@ config ARMSSE >>> select IOTKIT_SECCTL >>> select IOTKIT_SYSCTL >>> select IOTKIT_SYSINFO >>> + select OR_IRQ >>> select TZ_MPC >>> select TZ_MSC >>> select TZ_PPC >> >> In cases like this where a device is used both by >> an SoC and also directly by the board code that uses >> that SoC, should we put the select OR_IRQ only in >> the SoC's config, or also in the board model's config >> (ie, in "config MPS2" as well as "config ARMSSE") ? > > Someone should be able to work on the board without having to look at > the SoC code/config, so both :) The idea of Kconfig is you only worry > about a specific device, and the qgraph sort the rest out.
I don't have a strong opinion here, but likely is safer indeed to put the switch into both sections in this case - so if one of the two ever gets changed, the config switch is still there for the other one that still requires it. I'll send a v2. Thomas
