From: Saravana Kannan <saravanak@google.com> To: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Rob Herring <robh+dt@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org, Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Ruizhe Lin <linruizhe@huawei.com> Subject: Re: [PATCH 3/3] amba: Properly handle device probe without IRQ domain Date: Wed, 25 Aug 2021 21:45:40 -0700 [thread overview] Message-ID: <CAGETcx9yaWZOzt=gcyNAshoHdPoYizhmrKS-kU9c2QM2+HqeEw@mail.gmail.com> (raw) In-Reply-To: <b5eb935f-26e1-6475-63af-e7f6101eb017@huawei.com> On Wed, Aug 25, 2021 at 7:45 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > On 2021/8/25 16:04, Saravana Kannan wrote: > > On Tue, Aug 24, 2021 at 9:05 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> > >> On 2021/8/25 4:08, Saravana Kannan wrote: > >>> On Tue, Aug 24, 2021 at 1:05 PM Rob Herring <robh+dt@kernel.org> 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@huawei.com> 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@armlinux.org.uk> > >>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>> Cc: Frank Rowand <frowand.list@gmail.com> > >>>>> Reported-by: Ruizhe Lin <linruizhe@huawei.com> > >>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > >>>>> --- > >>>>> drivers/amba/bus.c | 27 +++++++++++++++++++++++++++ > >>>>> drivers/of/platform.c | 6 +----- > >>>>> 2 files changed, 28 insertions(+), 5 deletions(-) > >>>>> > >>>>> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c > >>>>> index 36f2f42c8014..720aa6cdd402 100644 > >>>>> --- a/drivers/amba/bus.c > >>>>> +++ b/drivers/amba/bus.c > >>>>> @@ -19,6 +19,7 @@ > >>>>> #include <linux/clk/clk-conf.h> > >>>>> #include <linux/platform_device.h> > >>>>> #include <linux/reset.h> > >>>>> +#include <linux/of_irq.h> > >>>>> > >>>>> #include <asm/irq.h> > >>>>> > >>>>> @@ -371,12 +372,38 @@ static void amba_device_release(struct device *dev) > >>>>> kfree(d); > >>>>> } > >>>>> > >>>>> +static int of_amba_device_decode_irq(struct amba_device *dev) > >>>>> +{ > >>>>> + struct device_node *node = dev->dev.of_node; > >>>>> + int i, irq = 0; > >>>>> + > >>>>> + if (IS_ENABLED(CONFIG_OF_IRQ) && node) { > >>>>> + /* Decode the IRQs and address ranges */ > >>>>> + for (i = 0; i < AMBA_NR_IRQS; i++) { > >>>>> + irq = of_irq_get(node, i); > >>>>> + if (irq < 0) { > >>>>> + if (irq == -EPROBE_DEFER) > >>>>> + return irq; > >>>>> + irq = 0; > >>>>> + } > >>>>> + > >>>>> + dev->irq[i] = irq; > >>>>> + } > >>>>> + } > >>>>> + > >>>>> + return 0; > >>>>> +} > >>>>> + > >>>>> static int amba_device_try_add(struct amba_device *dev, struct resource *parent) > >>>>> { > >>>>> u32 size; > >>>>> void __iomem *tmp; > >>>>> int i, ret; > >>>>> > >>>>> + ret = of_amba_device_decode_irq(dev); > >>>>> + if (ret) > >>>>> + goto err_out; > >>>>> + > >>> Similar to other resources the AMBA bus "gets" for the device, I think > >>> 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. > >> The following code in the amba_device_try_add() will be called, it uses irq[0] > >> 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? > > But delaying the device add is the issue. For example, adding a device > > 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 we > >> make a new patch to move both of them, or don't move them? > > I'd say move them both. If Russell hasn't already picked this up, then > > I'd say redo your Patch 3/3. > I will resend with put it into amba_probe. > > > > Btw, I've been working on [1] cleaning up the one-off deferred probe > > 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. > > Got it, and I could resend all combine your patch(due to context conflict > > when changing same function) if you no object. If you want to resolve the conflict with my patch and resend it while keeping me as the author, I would definitely appreciate it. -Saravana > > > > > > -Saravana > > > > [1] - https://lore.kernel.org/lkml/CAGETcx8b228nDUho3cX9AAQ-pXOfZTMv8cj2vhdx9yc_pk8q+A@mail.gmail.com/ > > . > >
WARNING: multiple messages have this Message-ID (diff)
From: Saravana Kannan <saravanak@google.com> To: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Rob Herring <robh+dt@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Frank Rowand <frowand.list@gmail.com>, devicetree@vger.kernel.org, Russell King <linux@armlinux.org.uk>, Linus Walleij <linus.walleij@linaro.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Ruizhe Lin <linruizhe@huawei.com> Subject: Re: [PATCH 3/3] amba: Properly handle device probe without IRQ domain Date: Wed, 25 Aug 2021 21:45:40 -0700 [thread overview] Message-ID: <CAGETcx9yaWZOzt=gcyNAshoHdPoYizhmrKS-kU9c2QM2+HqeEw@mail.gmail.com> (raw) In-Reply-To: <b5eb935f-26e1-6475-63af-e7f6101eb017@huawei.com> On Wed, Aug 25, 2021 at 7:45 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > On 2021/8/25 16:04, Saravana Kannan wrote: > > On Tue, Aug 24, 2021 at 9:05 PM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> > >> On 2021/8/25 4:08, Saravana Kannan wrote: > >>> On Tue, Aug 24, 2021 at 1:05 PM Rob Herring <robh+dt@kernel.org> 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@huawei.com> 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@armlinux.org.uk> > >>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>> Cc: Frank Rowand <frowand.list@gmail.com> > >>>>> Reported-by: Ruizhe Lin <linruizhe@huawei.com> > >>>>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > >>>>> --- > >>>>> drivers/amba/bus.c | 27 +++++++++++++++++++++++++++ > >>>>> drivers/of/platform.c | 6 +----- > >>>>> 2 files changed, 28 insertions(+), 5 deletions(-) > >>>>> > >>>>> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c > >>>>> index 36f2f42c8014..720aa6cdd402 100644 > >>>>> --- a/drivers/amba/bus.c > >>>>> +++ b/drivers/amba/bus.c > >>>>> @@ -19,6 +19,7 @@ > >>>>> #include <linux/clk/clk-conf.h> > >>>>> #include <linux/platform_device.h> > >>>>> #include <linux/reset.h> > >>>>> +#include <linux/of_irq.h> > >>>>> > >>>>> #include <asm/irq.h> > >>>>> > >>>>> @@ -371,12 +372,38 @@ static void amba_device_release(struct device *dev) > >>>>> kfree(d); > >>>>> } > >>>>> > >>>>> +static int of_amba_device_decode_irq(struct amba_device *dev) > >>>>> +{ > >>>>> + struct device_node *node = dev->dev.of_node; > >>>>> + int i, irq = 0; > >>>>> + > >>>>> + if (IS_ENABLED(CONFIG_OF_IRQ) && node) { > >>>>> + /* Decode the IRQs and address ranges */ > >>>>> + for (i = 0; i < AMBA_NR_IRQS; i++) { > >>>>> + irq = of_irq_get(node, i); > >>>>> + if (irq < 0) { > >>>>> + if (irq == -EPROBE_DEFER) > >>>>> + return irq; > >>>>> + irq = 0; > >>>>> + } > >>>>> + > >>>>> + dev->irq[i] = irq; > >>>>> + } > >>>>> + } > >>>>> + > >>>>> + return 0; > >>>>> +} > >>>>> + > >>>>> static int amba_device_try_add(struct amba_device *dev, struct resource *parent) > >>>>> { > >>>>> u32 size; > >>>>> void __iomem *tmp; > >>>>> int i, ret; > >>>>> > >>>>> + ret = of_amba_device_decode_irq(dev); > >>>>> + if (ret) > >>>>> + goto err_out; > >>>>> + > >>> Similar to other resources the AMBA bus "gets" for the device, I think > >>> 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. > >> The following code in the amba_device_try_add() will be called, it uses irq[0] > >> 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? > > But delaying the device add is the issue. For example, adding a device > > 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 we > >> make a new patch to move both of them, or don't move them? > > I'd say move them both. If Russell hasn't already picked this up, then > > I'd say redo your Patch 3/3. > I will resend with put it into amba_probe. > > > > Btw, I've been working on [1] cleaning up the one-off deferred probe > > 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. > > Got it, and I could resend all combine your patch(due to context conflict > > when changing same function) if you no object. If you want to resolve the conflict with my patch and resend it while keeping me as the author, I would definitely appreciate it. -Saravana > > > > > > -Saravana > > > > [1] - https://lore.kernel.org/lkml/CAGETcx8b228nDUho3cX9AAQ-pXOfZTMv8cj2vhdx9yc_pk8q+A@mail.gmail.com/ > > . > > _______________________________________________ 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:[~2021-08-26 4:46 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-16 7:46 [PATCH 0/3] amba: Properly handle device probe without IRQ domain Kefeng Wang 2021-08-16 7:46 ` Kefeng Wang 2021-08-16 7:46 ` [PATCH 1/3] amba: Drop unused functions about APB/AHB devices add Kefeng Wang 2021-08-16 7:46 ` Kefeng Wang 2021-08-16 7:46 ` [PATCH 2/3] Revert "ARM: amba: make use of -1 IRQs warn" Kefeng Wang 2021-08-16 7:46 ` Kefeng Wang 2021-08-16 7:46 ` [PATCH 3/3] amba: Properly handle device probe without IRQ domain Kefeng Wang 2021-08-16 7:46 ` Kefeng Wang 2021-08-24 20:05 ` Rob Herring 2021-08-24 20:05 ` Rob Herring 2021-08-24 20:08 ` Saravana Kannan 2021-08-24 20:08 ` Saravana Kannan 2021-08-25 4:05 ` Kefeng Wang 2021-08-25 4:05 ` Kefeng Wang 2021-08-25 8:04 ` Saravana Kannan 2021-08-25 8:04 ` Saravana Kannan 2021-08-25 8:39 ` Kefeng Wang 2021-08-25 8:39 ` Kefeng Wang 2021-08-26 2:45 ` Kefeng Wang 2021-08-26 2:45 ` Kefeng Wang 2021-08-26 4:45 ` Saravana Kannan [this message] 2021-08-26 4:45 ` Saravana Kannan 2021-08-26 6:22 ` Kefeng Wang 2021-08-26 6:22 ` Kefeng Wang 2021-08-26 8:22 ` [BUG] amba: Remove deferred device addition Kefeng Wang 2021-08-27 0:04 ` Saravana Kannan 2021-08-27 0:04 ` Saravana Kannan 2021-08-27 14:38 ` Kefeng Wang 2021-08-27 19:09 ` Saravana Kannan 2021-08-27 19:09 ` Saravana Kannan 2021-08-28 1:09 ` Kefeng Wang 2021-08-28 1:09 ` Kefeng Wang 2021-09-09 3:30 ` Saravana Kannan 2021-09-09 3:30 ` Saravana Kannan 2021-09-10 7:59 ` Kefeng Wang 2021-09-10 7:59 ` Kefeng Wang 2022-07-05 19:25 ` Saravana Kannan 2022-07-05 19:25 ` Saravana Kannan 2022-08-27 10:26 ` Leizhen (ThunderTown) 2022-08-27 10:26 ` Leizhen (ThunderTown) 2021-08-25 12:33 ` [PATCH 3/3] amba: Properly handle device probe without IRQ domain Rob Herring 2021-08-25 12:33 ` Rob Herring 2021-08-25 14:41 ` Kefeng Wang 2021-08-25 14:41 ` Kefeng Wang 2021-08-17 22:27 ` [PATCH 0/3] " Rob Herring 2021-08-17 22:27 ` Rob Herring 2021-08-23 2:19 ` Kefeng Wang 2021-08-23 2:19 ` Kefeng Wang 2021-08-23 9:05 ` Russell King (Oracle) 2021-08-23 9:05 ` Russell King (Oracle) 2021-08-23 10:57 ` Kefeng Wang 2021-08-23 10:57 ` Kefeng Wang
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='CAGETcx9yaWZOzt=gcyNAshoHdPoYizhmrKS-kU9c2QM2+HqeEw@mail.gmail.com' \ --to=saravanak@google.com \ --cc=devicetree@vger.kernel.org \ --cc=frowand.list@gmail.com \ --cc=linruizhe@huawei.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=robh+dt@kernel.org \ --cc=wangkefeng.wang@huawei.com \ /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: linkBe 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.