From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Frank Wunderlich <linux@fw-web.de>,
John Stultz <john.stultz@linaro.org>,
Saravana Kannan <saravanak@google.com>,
Hanks Chen <hanks.chen@mediatek.com>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Frank Rowand <frowand.list@gmail.com>,
kernel-team@android.com
Subject: Re: [PATCH 0/6] irqchip: Hybrid probing
Date: Wed, 16 Sep 2020 09:51:13 +0100 [thread overview]
Message-ID: <cd0a52739dcb3b238a1c600d46cad711@kernel.org> (raw)
In-Reply-To: <20200915211354.GA2469362@bogus>
On 2020-09-15 22:13, Rob Herring wrote:
> On Sat, Sep 12, 2020 at 01:51:42PM +0100, Marc Zyngier wrote:
>> A recent attempt at converting a couple of interrupt controllers from
>> early probing to standard platform drivers have badly failed, as it
>> became evident that although an interrupt controller can easily probe
>> late, device drivers for the endpoints connected to it are rarely
>> equipped to deal with probe deferral. Changes were swiftly reverted.
>>
>> However, there is some value in *optionally* enabling this, if only
>> for development purposes, as there is otherwise a "chicken and egg"
>> problem, and a few people (cc'd) are working on a potential solution.
>>
>> This short series enables the infrastructure for modular building
>> whilst retaining the usual early probing for monolithic build, and
>> introduces it to the three drivers that were previously made to probe
>> as platform drivers.
>
> I hardly expected more OF_DECLARE macros when I opened this up. Given
> desires to get rid of them, I don't think adding to it is the way
> forward. That wrapping a platform driver around OF_DECLARE looks pretty
> horrible IMO.
Nobody said it was cute. It's a band aid that allows us to move from the
status-quo that exists today. How would you propose we allow people to
go and start "fixing" drivers if you don't give them the opportunity
to even start trying?
> I browsed some of the discussion around this. It didn't seem like it's
> a large number of drivers that have to be fixed to defer probe
> correctly. Am I missing something?
Well, that was enough drivers for the two platforms that had it enabled
to break horribly, without a way to go back to a working state. Do you
find that acceptable? I don't.
> I'd rather keep the pressure on getting fw_devlink on by default.
So far, fw_devlink breaks everything under the sun, even without modular
irqchips. Most of my systems fail to boot if I enable it. So yes, it
really needs some work. And this series allows this work to happen.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Saravana Kannan <saravanak@google.com>,
kernel-team@android.com, Hanks Chen <hanks.chen@mediatek.com>,
linux-kernel@vger.kernel.org,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Andy Gross <agross@kernel.org>,
John Stultz <john.stultz@linaro.org>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Frank Wunderlich <linux@fw-web.de>,
Frank Rowand <frowand.list@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/6] irqchip: Hybrid probing
Date: Wed, 16 Sep 2020 09:51:13 +0100 [thread overview]
Message-ID: <cd0a52739dcb3b238a1c600d46cad711@kernel.org> (raw)
In-Reply-To: <20200915211354.GA2469362@bogus>
On 2020-09-15 22:13, Rob Herring wrote:
> On Sat, Sep 12, 2020 at 01:51:42PM +0100, Marc Zyngier wrote:
>> A recent attempt at converting a couple of interrupt controllers from
>> early probing to standard platform drivers have badly failed, as it
>> became evident that although an interrupt controller can easily probe
>> late, device drivers for the endpoints connected to it are rarely
>> equipped to deal with probe deferral. Changes were swiftly reverted.
>>
>> However, there is some value in *optionally* enabling this, if only
>> for development purposes, as there is otherwise a "chicken and egg"
>> problem, and a few people (cc'd) are working on a potential solution.
>>
>> This short series enables the infrastructure for modular building
>> whilst retaining the usual early probing for monolithic build, and
>> introduces it to the three drivers that were previously made to probe
>> as platform drivers.
>
> I hardly expected more OF_DECLARE macros when I opened this up. Given
> desires to get rid of them, I don't think adding to it is the way
> forward. That wrapping a platform driver around OF_DECLARE looks pretty
> horrible IMO.
Nobody said it was cute. It's a band aid that allows us to move from the
status-quo that exists today. How would you propose we allow people to
go and start "fixing" drivers if you don't give them the opportunity
to even start trying?
> I browsed some of the discussion around this. It didn't seem like it's
> a large number of drivers that have to be fixed to defer probe
> correctly. Am I missing something?
Well, that was enough drivers for the two platforms that had it enabled
to break horribly, without a way to go back to a working state. Do you
find that acceptable? I don't.
> I'd rather keep the pressure on getting fw_devlink on by default.
So far, fw_devlink breaks everything under the sun, even without modular
irqchips. Most of my systems fail to boot if I enable it. So yes, it
really needs some work. And this series allows this work to happen.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-16 8:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-12 12:51 [PATCH 0/6] irqchip: Hybrid probing Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 12:51 ` [PATCH 1/6] of: Add basic infrastructure to create early probe arrays Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 23:20 ` Bjorn Andersson
2020-09-12 23:20 ` Bjorn Andersson
2020-09-13 2:40 ` Bjorn Andersson
2020-09-13 2:40 ` Bjorn Andersson
2020-09-12 12:51 ` [PATCH 2/6] irqchip: Make IRQCHIP_MATCH() type safe Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 23:20 ` Bjorn Andersson
2020-09-12 23:20 ` Bjorn Andersson
2020-09-12 12:51 ` [PATCH 3/6] irqchip: Introduce IRQCHIP_HYBRID_DRIVER_{BEGIN,END} macros Marc Zyngier
2020-09-12 12:51 ` [PATCH 3/6] irqchip: Introduce IRQCHIP_HYBRID_DRIVER_{BEGIN, END} macros Marc Zyngier
2020-09-12 23:21 ` [PATCH 3/6] irqchip: Introduce IRQCHIP_HYBRID_DRIVER_{BEGIN,END} macros Bjorn Andersson
2020-09-12 23:21 ` [PATCH 3/6] irqchip: Introduce IRQCHIP_HYBRID_DRIVER_{BEGIN, END} macros Bjorn Andersson
2020-09-12 12:51 ` [PATCH 4/6] irqchip/mtk-cirq: Allow modular build Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 23:22 ` Bjorn Andersson
2020-09-12 23:22 ` Bjorn Andersson
2020-09-16 8:26 ` Enric Balletbo Serra
2020-09-16 8:26 ` Enric Balletbo Serra
2020-09-12 12:51 ` [PATCH 5/6] irqchip/mtk-sysirq: " Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 23:22 ` Bjorn Andersson
2020-09-12 23:22 ` Bjorn Andersson
2020-09-16 8:22 ` Enric Balletbo Serra
2020-09-16 8:22 ` Enric Balletbo Serra
2020-09-12 12:51 ` [PATCH 6/6] irqchip/qcom-pdc: " Marc Zyngier
2020-09-12 12:51 ` Marc Zyngier
2020-09-12 23:22 ` Bjorn Andersson
2020-09-12 23:22 ` Bjorn Andersson
2020-09-14 21:04 ` [PATCH] irqchip/qcom-pdc: Allow QCOM_PDC to be loadable as a permanent module John Stultz
2020-09-14 21:04 ` John Stultz
2020-09-15 6:56 ` Greg Kroah-Hartman
2020-09-15 6:56 ` Greg Kroah-Hartman
2020-09-15 15:44 ` Bjorn Andersson
2020-09-15 15:44 ` Bjorn Andersson
2020-09-14 20:33 ` [PATCH 0/6] irqchip: Hybrid probing John Stultz
2020-09-14 20:33 ` John Stultz
2020-09-15 21:13 ` Rob Herring
2020-09-15 21:13 ` Rob Herring
2020-09-16 8:51 ` Marc Zyngier [this message]
2020-09-16 8:51 ` Marc Zyngier
2020-09-16 15:18 ` Rob Herring
2020-09-16 15:18 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd0a52739dcb3b238a1c600d46cad711@kernel.org \
--to=maz@kernel.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=frowand.list@gmail.com \
--cc=hanks.chen@mediatek.com \
--cc=jason@lakedaemon.net \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@fw-web.de \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.