Hi All,
This patch series aims to drop using platform_get_resource() for IRQ types
in preparation for removal of static setup of IRQ resource from DT core
code.
Dropping usage of platform_get_resource() was agreed based on
the discussion [0].
[0] https://patchwork.kernel.org/project/linux-renesas-soc/
patch/[email protected]/
Cheers,
Prabhakar
Lad Prabhakar (3):
i2c: bcm2835: Use platform_get_irq() to get the interrupt
i2c: sh_mobile: Use platform_get_irq_optional() to get the interrupt
i2c: riic: Use platform_get_irq() to get the interrupt
drivers/i2c/busses/i2c-bcm2835.c | 11 ++++------
drivers/i2c/busses/i2c-riic.c | 10 ++++-----
drivers/i2c/busses/i2c-sh_mobile.c | 34 +++++++++++++++++++++++-------
3 files changed, 35 insertions(+), 20 deletions(-)
--
2.17.1
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <[email protected]>
---
v1->v2
* Dropped IRQ0 check
---
drivers/i2c/busses/i2c-bcm2835.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 37443edbf754..dfc534065595 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -402,7 +402,7 @@ static const struct i2c_adapter_quirks bcm2835_i2c_quirks = {
static int bcm2835_i2c_probe(struct platform_device *pdev)
{
struct bcm2835_i2c_dev *i2c_dev;
- struct resource *mem, *irq;
+ struct resource *mem;
int ret;
struct i2c_adapter *adap;
struct clk *mclk;
@@ -452,12 +452,9 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
return ret;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
- dev_err(&pdev->dev, "No IRQ resource\n");
- return -ENODEV;
- }
- i2c_dev->irq = irq->start;
+ i2c_dev->irq = platform_get_irq(pdev, 0);
+ if (i2c_dev->irq < 0)
+ return i2c_dev->irq;
ret = request_irq(i2c_dev->irq, bcm2835_i2c_isr, IRQF_SHARED,
dev_name(&pdev->dev), i2c_dev);
--
2.17.1
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq_optional() for DT users only.
Signed-off-by: Lad Prabhakar <[email protected]>
---
v1->v2
* Dropped IRQ0 check
* Simplified code
---
drivers/i2c/busses/i2c-sh_mobile.c | 34 +++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 7b8caf172851..9754849dbb23 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -830,20 +830,38 @@ static void sh_mobile_i2c_release_dma(struct sh_mobile_i2c_data *pd)
static int sh_mobile_i2c_hook_irqs(struct platform_device *dev, struct sh_mobile_i2c_data *pd)
{
- struct resource *res;
- resource_size_t n;
+ struct device_node *np = dev_of_node(&dev->dev);
int k = 0, ret;
- while ((res = platform_get_resource(dev, IORESOURCE_IRQ, k))) {
- for (n = res->start; n <= res->end; n++) {
- ret = devm_request_irq(&dev->dev, n, sh_mobile_i2c_isr,
- 0, dev_name(&dev->dev), pd);
+ if (np) {
+ int irq;
+
+ while ((irq = platform_get_irq_optional(dev, k)) != -ENXIO) {
+ if (irq < 0)
+ return irq;
+ ret = devm_request_irq(&dev->dev, irq, sh_mobile_i2c_isr,
+ 0, dev_name(&dev->dev), pd);
if (ret) {
- dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
+ dev_err(&dev->dev, "cannot request IRQ %d\n", irq);
return ret;
}
+ k++;
+ };
+ } else {
+ struct resource *res;
+ resource_size_t n;
+
+ while ((res = platform_get_resource(dev, IORESOURCE_IRQ, k))) {
+ for (n = res->start; n <= res->end; n++) {
+ ret = devm_request_irq(&dev->dev, n, sh_mobile_i2c_isr,
+ 0, dev_name(&dev->dev), pd);
+ if (ret) {
+ dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
+ return ret;
+ }
+ }
+ k++;
}
- k++;
}
return k > 0 ? 0 : -ENOENT;
--
2.17.1
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
allocation of IRQ resources in DT core code, this causes an issue
when using hierarchical interrupt domains using "interrupts" property
in the node as this bypasses the hierarchical setup and messes up the
irq chaining.
In preparation for removal of static setup of IRQ resource from DT core
code use platform_get_irq().
Signed-off-by: Lad Prabhakar <[email protected]>
---
v1->v2
* Dropped IRQ0 check
---
drivers/i2c/busses/i2c-riic.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-riic.c b/drivers/i2c/busses/i2c-riic.c
index 78b84445ee6a..8dfd27dc6149 100644
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -433,12 +433,12 @@ static int riic_i2c_probe(struct platform_device *pdev)
}
for (i = 0; i < ARRAY_SIZE(riic_irqs); i++) {
- res = platform_get_resource(pdev, IORESOURCE_IRQ, riic_irqs[i].res_num);
- if (!res)
- return -ENODEV;
+ ret = platform_get_irq(pdev, riic_irqs[i].res_num);
+ if (ret < 0)
+ return ret;
- ret = devm_request_irq(&pdev->dev, res->start, riic_irqs[i].isr,
- 0, riic_irqs[i].name, riic);
+ ret = devm_request_irq(&pdev->dev, ret, riic_irqs[i].isr,
+ 0, riic_irqs[i].name, riic);
if (ret) {
dev_err(&pdev->dev, "failed to request irq %s\n", riic_irqs[i].name);
return ret;
--
2.17.1
On 12/21/21 9:53 AM, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
--
Florian
On Tue, Dec 21, 2021 at 7:21 PM Lad Prabhakar
<[email protected]> wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq_optional() for DT users only.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Dec 21, 2021 at 05:53:21PM +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq_optional() for DT users only.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Tested on a Renesas R-Car Gen3 SoC (M3-W) and IIC port still works and
no false positive printouts in the kernel log:
Reviewed-by: Wolfram Sang <[email protected]>
Tested-by: Wolfram Sang <[email protected]>
On Tue, Dec 21, 2021 at 05:53:22PM +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Wolfram Sang <[email protected]>
On Tue, Dec 21, 2021 at 7:25 PM Lad Prabhakar
<[email protected]> wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Dec 22, 2021 at 2:41 PM Lad Prabhakar
<[email protected]> wrote:
>
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq_optional() for DT users only.
...
> + if (np) {
Same comments as per your other patches, i.e.
Why is this check here?
> + int irq;
> +
> + while ((irq = platform_get_irq_optional(dev, k)) != -ENXIO) {
Consider 0 as no IRQ.
> + if (irq < 0)
> + return irq;
> + ret = devm_request_irq(&dev->dev, irq, sh_mobile_i2c_isr,
> + 0, dev_name(&dev->dev), pd);
> if (ret) {
> - dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
> + dev_err(&dev->dev, "cannot request IRQ %d\n", irq);
> return ret;
> }
> + k++;
> + };
> + } else {
> + struct resource *res;
> + resource_size_t n;
> +
> + while ((res = platform_get_resource(dev, IORESOURCE_IRQ, k))) {
> + for (n = res->start; n <= res->end; n++) {
> + ret = devm_request_irq(&dev->dev, n, sh_mobile_i2c_isr,
> + 0, dev_name(&dev->dev), pd);
> + if (ret) {
> + dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
> + return ret;
> + }
> + }
> + k++;
> }
> - k++;
> }
--
With Best Regards,
Andy Shevchenko
Hi Andy,
Thank you for the review.
> -----Original Message-----
> From: Andy Shevchenko <[email protected]>
> Sent: 25 December 2021 17:49
> To: Prabhakar Mahadev Lad <[email protected]>
> Cc: Florian Fainelli <[email protected]>; Ray Jui <[email protected]>; Scott Branden
> <[email protected]>; bcm-kernel-feedback-list <[email protected]>; Nicolas
> Saenz Julienne <[email protected]>; Chris Brandt <[email protected]>; Wolfram Sang
> <[email protected]>; linux-i2c <[email protected]>; linux-rpi-kernel <linux-
> [email protected]>; linux-arm Mailing List <[email protected]>; Linux-
> Renesas <[email protected]>; Linux Kernel Mailing List <[email protected]>;
> [email protected]
> Subject: Re: [PATCH v2 2/3] i2c: sh_mobile: Use platform_get_irq_optional() to get the interrupt
>
> On Wed, Dec 22, 2021 at 2:41 PM Lad Prabhakar <[email protected]> wrote:
> >
> > platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> > allocation of IRQ resources in DT core code, this causes an issue when
> > using hierarchical interrupt domains using "interrupts" property in
> > the node as this bypasses the hierarchical setup and messes up the irq
> > chaining.
> >
> > In preparation for removal of static setup of IRQ resource from DT
> > core code use platform_get_irq_optional() for DT users only.
>
> ...
>
> > + if (np) {
>
> Same comments as per your other patches, i.e.
> Why is this check here?
>
Because the interrupt resource has range of interrupts in one IRQ resource [0]. Let me know if there is any other alternative way to avoid such case.
> > + int irq;
> > +
> > + while ((irq = platform_get_irq_optional(dev, k)) !=
> > + -ENXIO) {
>
> Consider 0 as no IRQ.
>
OK.
[0] https://elixir.bootlin.com/linux/v5.16-rc6/source/arch/sh/kernel/cpu/sh4a/setup-sh7724.c#L454
Cheers,
Prabhakar
> > + if (irq < 0)
> > + return irq;
> > + ret = devm_request_irq(&dev->dev, irq, sh_mobile_i2c_isr,
> > + 0, dev_name(&dev->dev),
> > + pd);
> > if (ret) {
> > - dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
> > + dev_err(&dev->dev, "cannot request IRQ
> > + %d\n", irq);
> > return ret;
> > }
> > + k++;
> > + };
> > + } else {
> > + struct resource *res;
> > + resource_size_t n;
> > +
> > + while ((res = platform_get_resource(dev, IORESOURCE_IRQ, k))) {
> > + for (n = res->start; n <= res->end; n++) {
> > + ret = devm_request_irq(&dev->dev, n, sh_mobile_i2c_isr,
> > + 0, dev_name(&dev->dev), pd);
> > + if (ret) {
> > + dev_err(&dev->dev, "cannot request IRQ %pa\n", &n);
> > + return ret;
> > + }
> > + }
> > + k++;
> > }
> > - k++;
> > }
>
> --
> With Best Regards,
> Andy Shevchenko
On Sun, Dec 26, 2021 at 1:45 AM Prabhakar Mahadev Lad
<[email protected]> wrote:
> > On Wed, Dec 22, 2021 at 2:41 PM Lad Prabhakar <[email protected]> wrote:
...
> > > + if (np) {
> >
> > Same comments as per your other patches, i.e.
> > Why is this check here?
> >
> Because the interrupt resource has range of interrupts in one IRQ resource [0]. Let me know if there is any other alternative way to avoid such case.
Shouldn't be fixed in platform_get_irq_optional() to return IRQ by
index for all cases?
> [0] https://elixir.bootlin.com/linux/v5.16-rc6/source/arch/sh/kernel/cpu/sh4a/setup-sh7724.c#L454
--
With Best Regards,
Andy Shevchenko
On Sun, Dec 26, 2021 at 8:41 AM Andy Shevchenko
<[email protected]> wrote:
>
> On Sun, Dec 26, 2021 at 1:45 AM Prabhakar Mahadev Lad
> <[email protected]> wrote:
> > > On Wed, Dec 22, 2021 at 2:41 PM Lad Prabhakar <[email protected]> wrote:
>
> ...
>
> > > > + if (np) {
> > >
> > > Same comments as per your other patches, i.e.
> > > Why is this check here?
> > >
> > Because the interrupt resource has range of interrupts in one IRQ resource [0]. Let me know if there is any other alternative way to avoid such case.
>
> Shouldn't be fixed in platform_get_irq_optional() to return IRQ by
> index for all cases?
>
Sorry, I don't get you here. Wasn't your earlier comment for np check?
Cheers,
Prabhakar
On Tue, Dec 21, 2021 at 05:53:20PM +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Applied to for-next, thanks!
On Tue, Dec 21, 2021 at 05:53:21PM +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq_optional() for DT users only.
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Applied to for-next, thanks!
On Tue, Dec 21, 2021 at 05:53:22PM +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq().
>
> Signed-off-by: Lad Prabhakar <[email protected]>
Applied to for-next, thanks!