linux-kernel - Re: [PATCH 0/3] IRQ_DOMAIN: remove all "depends on", use only "select"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <30194f43-10c1-faa8-f952-99cc30f5c128@infradead.org>
Date:   Tue, 28 Feb 2023 15:04:42 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Donggeun Kim <dg77.kim@...sung.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Peter Rosin <peda@...ntia.se>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Rob Herring <robh@...nel.org>,
        Eddie Huang <eddie.huang@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        linux-rtc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 0/3] IRQ_DOMAIN: remove all "depends on", use only
 "select"



On 2/28/23 11:29, Marc Zyngier wrote:
> On Thu, 23 Feb 2023 18:37:01 +0000,
> Randy Dunlap <rdunlap@...radead.org> wrote:
>>
>> Hi Marc,
>>
>> On 2/14/23 11:56, Marc Zyngier wrote:
>>> On Tue, 14 Feb 2023 18:30:54 +0000,
>>> Randy Dunlap <rdunlap@...radead.org> 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