This contains two fixes for the ocelot pinctrl:
- first fixes the memory resource index for pincfg
- second fixes the interrupt parsing
v1->v2:
- add Reviewed-by tag for patch 1
- use platform_get_irq_optional instead of irq_of_parse_and_map
Horatiu Vultur (2):
pinctrl: ocelot: Fix the pincfg resource.
pinctrl: ocelot: Fix interrupt parsing
drivers/pinctrl/pinctrl-ocelot.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.33.0
In the blamed commit, it removes the duplicate of_node assignment in the
driver. But the driver uses this before calling into of_gpio_dev_init to
determine if it needs to assign an IRQ chip to the GPIO. The fixes
consists in using the platform_get_irq_optional
Fixes: 8a8d6bbe1d3bc7 ("pinctrl: Get rid of duplicate of_node assignment in the drivers")
Signed-off-by: Horatiu Vultur <[email protected]>
---
drivers/pinctrl/pinctrl-ocelot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index a859fbcb09af..e8501dac2f04 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1851,8 +1851,8 @@ static int ocelot_gpiochip_register(struct platform_device *pdev,
gc->base = -1;
gc->label = "ocelot-gpio";
- irq = irq_of_parse_and_map(gc->of_node, 0);
- if (irq) {
+ irq = platform_get_irq_optional(pdev, 0);
+ if (irq > 0) {
girq = &gc->irq;
girq->chip = &ocelot_irqchip;
girq->parent_handler = ocelot_irq_handler;
--
2.33.0
The pincfg resources are in the second memory resource. But the driver
still tries to access the first memory resource to get the pincfg. This
is wrong therefore fix to access the second memory resource.
Reviewed-by: Colin Foster <[email protected]>
Fixes: ad96111e658a95 ("pinctrl: ocelot: combine get resource and ioremap into single call")
Signed-off-by: Horatiu Vultur <[email protected]>
---
drivers/pinctrl/pinctrl-ocelot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index 685c79e08d40..a859fbcb09af 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1892,7 +1892,7 @@ static struct regmap *ocelot_pinctrl_create_pincfg(struct platform_device *pdev)
.max_register = 32,
};
- base = devm_platform_ioremap_resource(pdev, 0);
+ base = devm_platform_ioremap_resource(pdev, 1);
if (IS_ERR(base)) {
dev_dbg(&pdev->dev, "Failed to ioremap config registers (no extended pinconf)\n");
return NULL;
--
2.33.0
> The pincfg resources are in the second memory resource. But the driver
> still tries to access the first memory resource to get the pincfg. This
> is wrong therefore fix to access the second memory resource.
>
> Reviewed-by: Colin Foster <[email protected]>
> Fixes: ad96111e658a95 ("pinctrl: ocelot: combine get resource and ioremap into single call")
> Signed-off-by: Horatiu Vultur <[email protected]>
There is already this patch pending, which does exactly
the same:
https://lore.kernel.org/linux-gpio/[email protected]/
FWIW, there is also this one:
https://lore.kernel.org/linux-gpio/[email protected]/
-michael
Am 2022-03-08 09:30, schrieb Horatiu Vultur:
> The 03/07/2022 13:45, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>> the content is safe
>>
>> > The pincfg resources are in the second memory resource. But the driver
>> > still tries to access the first memory resource to get the pincfg. This
>> > is wrong therefore fix to access the second memory resource.
>> >
>> > Reviewed-by: Colin Foster <[email protected]>
>> > Fixes: ad96111e658a95 ("pinctrl: ocelot: combine get resource and ioremap into single call")
>> > Signed-off-by: Horatiu Vultur <[email protected]>
>>
>> There is already this patch pending, which does exactly
>> the same:
>> https://lore.kernel.org/linux-gpio/[email protected]/
>
> Sorry, I have missed your patch.
> Should I resend this series where I will drop this patch? What is the
> correct approach?
Actually, I don't know. Maybe you don't need to do anything, Linus?
-michael
The 03/07/2022 13:45, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> > The pincfg resources are in the second memory resource. But the driver
> > still tries to access the first memory resource to get the pincfg. This
> > is wrong therefore fix to access the second memory resource.
> >
> > Reviewed-by: Colin Foster <[email protected]>
> > Fixes: ad96111e658a95 ("pinctrl: ocelot: combine get resource and ioremap into single call")
> > Signed-off-by: Horatiu Vultur <[email protected]>
>
> There is already this patch pending, which does exactly
> the same:
> https://lore.kernel.org/linux-gpio/[email protected]/
Sorry, I have missed your patch.
Should I resend this series where I will drop this patch? What is the
correct approach?
>
> FWIW, there is also this one:
> https://lore.kernel.org/linux-gpio/[email protected]/
>
> -michael
--
/Horatiu
On Tue, Mar 8, 2022 at 9:32 AM Michael Walle <[email protected]> wrote:
> Am 2022-03-08 09:30, schrieb Horatiu Vultur:
> > The 03/07/2022 13:45, Michael Walle wrote:
> >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> >> the content is safe
> >>
> >> > The pincfg resources are in the second memory resource. But the driver
> >> > still tries to access the first memory resource to get the pincfg. This
> >> > is wrong therefore fix to access the second memory resource.
> >> >
> >> > Reviewed-by: Colin Foster <[email protected]>
> >> > Fixes: ad96111e658a95 ("pinctrl: ocelot: combine get resource and ioremap into single call")
> >> > Signed-off-by: Horatiu Vultur <[email protected]>
> >>
> >> There is already this patch pending, which does exactly
> >> the same:
> >> https://lore.kernel.org/linux-gpio/[email protected]/
> >
> > Sorry, I have missed your patch.
> > Should I resend this series where I will drop this patch? What is the
> > correct approach?
>
> Actually, I don't know. Maybe you don't need to do anything, Linus?
I'll just apply 2/2 if applicable.
Yours,
Linus Walleij
On Fri, Mar 4, 2022 at 3:42 PM Horatiu Vultur
<[email protected]> wrote:
> In the blamed commit, it removes the duplicate of_node assignment in the
> driver. But the driver uses this before calling into of_gpio_dev_init to
> determine if it needs to assign an IRQ chip to the GPIO. The fixes
> consists in using the platform_get_irq_optional
>
> Fixes: 8a8d6bbe1d3bc7 ("pinctrl: Get rid of duplicate of_node assignment in the drivers")
> Signed-off-by: Horatiu Vultur <[email protected]>
Patch applied.
Yours,
Linus Walleij