On Wed, Aug 25, 2021 at 7:45 PM Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> wrote:...
On 2021/8/25 16:04, Saravana Kannan wrote:
On Tue, Aug 24, 2021 at 9:05 PM Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> wrote:
On 2021/8/25 4:08, Saravana Kannan wrote:
On Tue, Aug 24, 2021 at 1:05 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
+Saravana
Saravana mentioned to me there may be some issues with this one...
On Mon, Aug 16, 2021 at 2:43 AM Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> wrote:
of_amba_device_create() uses irq_of_parse_and_map() to translate
a DT interrupt specification into a Linux virtual interrupt number.
But it doesn't properly handle the case where the interrupt controller
is not yet available, eg, when pl011 interrupt is connected to MBIGEN
interrupt controller, because the mbigen initialization is too late,
which will lead to no IRQ due to no IRQ domain found, log is shown below,
"irq: no irq domain found for uart0 !"
use of_irq_get() to return -EPROBE_DEFER as above, and in the function
amba_device_try_add()/amba_device_add(), it will properly handle in such
case, also return 0 in other fail cases to be consistent as before.
Cc: Russell King <linux@xxxxxxxxxxxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: Frank Rowand <frowand.list@xxxxxxxxx>
Reported-by: Ruizhe Lin <linruizhe@xxxxxxxxxx>
Signed-off-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx>
---
Yes, I will keep it, and rebase my patch based on it.If you want to resolve the conflict with my patch and resend it whileI will resend with put it into amba_probe.But delaying the device add is the issue. For example, adding a deviceSimilar to other resources the AMBA bus "gets" for the device, I thinkThe following code in the amba_device_try_add() will be called, it uses irq[0]
this should be moved into amba_probe() and not here. There's no reason
to delay the addition of the device (and loading its module) because
the IRQ isn't ready yet.
and irq[1], so I put of_amba_device_decode_irq() into amba_device_try_add().
470 if (dev->irq[0])
471 ret = device_create_file(&dev->dev, &dev_attr_irq0);
472 if (ret == 0 && dev->irq[1])
473 ret = device_create_file(&dev->dev, &dev_attr_irq1);
474 if (ret == 0)
475 return ret;
of_amba_device_decode_irq() in amba_device_try_add() won't lead to issue,
only delay the device add, right?
could trigger the loading of the corresponding module using uevents.
But now this change would delay that step. That can have other
unintended consequences -- slowing down boot, what if the driver was
working fine without the IRQ, etc.
If make it into amba_probe(), the above code should be moved too, could weI'd say move them both. If Russell hasn't already picked this up, then
make a new patch to move both of them, or don't move them?
I'd say redo your Patch 3/3.
Btw, I've been working on [1] cleaning up the one-off deferred probeGot it, and I could resend all combine your patch(due to context conflict
solution that we have for amba devices. That causes a bunch of other
headaches. Your patch 3/3 takes us further in the wrong direction by
adding more reasons for delaying the addition of the device.
when changing same function) if you no object.
keeping me as the author, I would definitely appreciate it.
-Saravana
.
-Saravana
[1] - https://lore.kernel.org/lkml/CAGETcx8b228nDUho3cX9AAQ-pXOfZTMv8cj2vhdx9yc_pk8q+A@xxxxxxxxxxxxxx/
.