On 2/28/23 11:29, Marc Zyngier wrote: > On Thu, 23 Feb 2023 18:37:01 +0000, > Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: >> >> Hi Marc, >> >> On 2/14/23 11:56, Marc Zyngier wrote: >>> On Tue, 14 Feb 2023 18:30:54 +0000, >>> Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: >>>> >>>> >>>> >>>> On 2/13/23 00:05, Arnd Bergmann wrote: >>>>> On Mon, Feb 13, 2023, at 05:15, Randy Dunlap wrote: >>>>>> IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set >>>>>> it directly thru "make *config", so drivers should select it instead >>>>>> of depending on it if they need it. >>>>>> Relying on it being set for a dependency is risky. >>>>>> >>>>>> Consistently using "select" or "depends on" can also help reduce >>>>>> Kconfig circular dependency issues. >>>>>> >>>>>> IRQ_DOMAIN is selected 109 times and is depended on 3 times in >>>>>> current linux-next. Eliminate the uses of "depends on" by >>>>>> converting them to "select". >>>>>> >>>>>> [PATCH 1/3] extcon: max8997: select IRQ_DOMAIN instead of depending on it >>>>>> [PATCH 2/3] of: OF_IRQ: select IRQ_DOMAIN instead of depending on it >>>>>> [PATCH 3/3] rtc: mt6397: select IRQ_DOMAIN instead of depending on it >>>>> >>>>> From a Kconfig perspective, your reasoning makes a lot of sense. >>>>> >>>>> Looking at the bigger picture, I wonder if we should just remove the >>>>> option and make it unconditional. It is enabled in ever architecture >>>>> defconfig other than alpha and sparc, and it's selected by a lot of >>>>> very common options such as I2C, GENERIC_MSI_IRQ, GENERIC_IRQ_CHIP, >>>>> and PCI_HOST_GENERIC. Enabling the option on Alpha grows the kernel >>>>> image from 9010KB to 9023KB, or on m68k Coldfire from 3346KB to >>>>> 3351KB. >>>> >>>> Marc, what do you think about this suggestion? >>> >>> Seems sensible enough to me. >>> >>> I'd also get rid of the IRQ_DOMAIN_HIERARCHY option, which is used by >>> a ton of things. Architectures that are not using it are either dead, >>> or at least terminally comatose. >>> >>> I'm half-tempted to put the following patch into -next. Maybe after >>> -rc1 though. And then the option can go as well. >>> >>> M. >> >> What is this patch based on? It doesn't apply cleanly to current linux-next. > > Not very surprising, I usually base my stuff on a stable rc tag. But > in this instance, it may have been based on whatever was in my sandbox > at that point in time, and subsequently discarded. > >> I made a similar patch (to linux-next) that drops the IRQ_DOMAIN_HIERARCHY >> option and converts its dependent code to always on. >> It has been built (multiple randconfigs) on all ARCHes (except hexagon), >> both 32-bit and 64-bit where applicable (not that it should matter here). >> >> But yes, let's plan to get one of these patches in soon (after -rc1). > > Please send it based on -rc1 once it is out, and I'll be happy to > stick that in -next for further simmering. Alrighty, will do. Thanks. -- ~Randy
