[PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

The commit breaks the legacy platforms, ie. these not using device-tree,
and setting up the interrupt resources with a flag to activate edge
detection. The issue was found on the zylonite platform.

The reason is that zylonite uses platform resources to pass the interrupt number
and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
request the irq with these flags, which in turn setups the irq as high edge
triggered.

After the patch, this was supposed to be taken care of with :
  irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));

But irq_resflags is 0 for legacy platforms, while for example in
arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
irq flag is specified. This breaks zylonite because the interrupt is not
setup as triggered, and hardware doesn't provide interrupts.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 drivers/net/ethernet/smsc/smc91x.c | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 88a55f9..5d77e6f 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2243,10 +2243,9 @@ static int smc_drv_probe(struct platform_device *pdev)
 	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
-	struct resource *res;
+	struct resource *res, *ires;
 	unsigned int __iomem *addr;
 	unsigned long irq_flags = SMC_IRQ_FLAGS;
-	unsigned long irq_resflags;
 	int ret;
 
 	ndev = alloc_etherdev(sizeof(struct smc_local));
@@ -2338,19 +2337,16 @@ static int smc_drv_probe(struct platform_device *pdev)
 		goto out_free_netdev;
 	}
 
-	ndev->irq = platform_get_irq(pdev, 0);
-	if (ndev->irq <= 0) {
+	ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!ires) {
 		ret = -ENODEV;
 		goto out_release_io;
 	}
-	/*
-	 * If this platform does not specify any special irqflags, or if
-	 * the resource supplies a trigger, override the irqflags with
-	 * the trigger flags from the resource.
-	 */
-	irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
-	if (irq_flags == -1 || irq_resflags & IRQF_TRIGGER_MASK)
-		irq_flags = irq_resflags & IRQF_TRIGGER_MASK;
+
+	ndev->irq = ires->start;
+
+	if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK)
+		irq_flags = ires->flags & IRQF_TRIGGER_MASK;
 
 	ret = smc_request_attrib(pdev, ndev);
 	if (ret)
-- 
2.1.0

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Linus Walleij]

On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:

> The commit breaks the legacy platforms, ie. these not using device-tree,
> and setting up the interrupt resources with a flag to activate edge
> detection. The issue was found on the zylonite platform.
>
> The reason is that zylonite uses platform resources to pass the interrupt number
> and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
> request the irq with these flags, which in turn setups the irq as high edge
> triggered.
>
> After the patch, this was supposed to be taken care of with :
>   irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
>
> But irq_resflags is 0 for legacy platforms, while for example in
> arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
> irq flag is specified. This breaks zylonite because the interrupt is not
> setup as triggered, and hardware doesn't provide interrupts.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>

But isn't the real problem that in the device tree case,
irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
from the device tree populates it correctly in platform_get_irq()
whereas for the legacy lookup it just fetches the number.

So to me it seems like a weakness in the platform_get_irq()
helper altogether.

Does the following work? (I can send as a separate patch for
testing if you like).

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9421fed40905..301f4b9ae908 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -101,6 +101,15 @@ int platform_get_irq(struct platform_device *dev,
unsigned int num)
     }

     r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+    /*
+     * The resources may pass trigger flags to the irqs that need
+     * to be set up. It so happens that the trigger flags for
+     * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
+     * settings.
+     */
+    if (r->flags & IORESOURCE_BITS)
+        irqd_set_trigger_type(irq_get_irq_data(r->start),
+                      r->flags & IORESOURCE_BITS);


Yours,
Linus Walleij

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> But isn't the real problem that in the device tree case,
> irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
> from the device tree populates it correctly in platform_get_irq()
> whereas for the legacy lookup it just fetches the number.
>
> So to me it seems like a weakness in the platform_get_irq()
> helper altogether.
>
> Does the following work? (I can send as a separate patch for
> testing if you like).

I will test this evening (GMT+1 time), I feel this will work, and that this
solution looks better to me than the sheer revert. I don't ask for a separate
patch, yet if it is confirmed that it works, you'll have to submit it anyway :)

Cheers.

--
Robert

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
> But isn't the real problem that in the device tree case,
> irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
> from the device tree populates it correctly in platform_get_irq()
> whereas for the legacy lookup it just fetches the number.
>
> So to me it seems like a weakness in the platform_get_irq()
> helper altogether.
>
> Does the following work? (I can send as a separate patch for
> testing if you like).

Almost. If you replace :
> +    if (r->flags & IORESOURCE_BITS)
with:
> +    if (r && r->flags & IORESOURCE_BITS)

Then you can push a patch with my:
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>

Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
you can't make it for 3.20, I'll push for the revert.

So I think it's up to you now, and let's see what Gregh says about it.

Cheers.

--
Robert

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
> But isn't the real problem that in the device tree case,
> irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
> from the device tree populates it correctly in platform_get_irq()
> whereas for the legacy lookup it just fetches the number.
>
> So to me it seems like a weakness in the platform_get_irq()
> helper altogether.
>
> Does the following work? (I can send as a separate patch for
> testing if you like).

Almost. If you replace :
> +    if (r->flags & IORESOURCE_BITS)
with:
> +    if (r && (r->flags & IORESOURCE_BITS))

Then you can push a patch with my:
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>

Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
you can't make it for 3.20, I'll push for the revert.

So I think it's up to you now, and let's see what Gregh says about it.

Cheers.

--
Robert

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[David Miller]

From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Fri, 13 Feb 2015 17:06:49 +0100

> Linus Walleij <linus.walleij@linaro.org> writes:
> 
>> On Fri, Feb 13, 2015 at 12:59 AM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>>
>> But isn't the real problem that in the device tree case,
>> irq_get_irq_data(ndev->irq) will work becaus parsing an interrupt
>> from the device tree populates it correctly in platform_get_irq()
>> whereas for the legacy lookup it just fetches the number.
>>
>> So to me it seems like a weakness in the platform_get_irq()
>> helper altogether.
>>
>> Does the following work? (I can send as a separate patch for
>> testing if you like).
> 
> Almost. If you replace :
>> +    if (r->flags & IORESOURCE_BITS)
> with:
>> +    if (r && r->flags & IORESOURCE_BITS)
> 
> Then you can push a patch with my:
> Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
> 
> Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
> you can't make it for 3.20, I'll push for the revert.
> 
> So I think it's up to you now, and let's see what Gregh says about it.

What is the current status of this?  I'd like to see this move forward so we
can get this fixed ASAP.

Thanks.

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

David Miller <davem@davemloft.net> writes:

>> Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
>> you can't make it for 3.20, I'll push for the revert.
>> 
>> So I think it's up to you now, and let's see what Gregh says about it.
>
> What is the current status of this?  I'd like to see this move forward so we
> can get this fixed ASAP.
Hi David,

Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
this is applied. If it's not, I'll reping you to apply this revert. Until then,
you can forget about it, I'll do the follow-up.

Does that plan sound good to you ?

Cheers.

-- 
Robert

[1] https://lkml.org/lkml/2015/2/18/310

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[David Miller]

From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Thu, 19 Feb 2015 21:48:49 +0100

> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
> this is applied. If it's not, I'll reping you to apply this revert. Until then,
> you can forget about it, I'll do the follow-up.
> 
> Does that plan sound good to you ?

It sounds good to me.

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Linus Walleij]

On Thu, Feb 19, 2015 at 9:48 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> David Miller <davem@davemloft.net> writes:
>
>>> Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
>>> you can't make it for 3.20, I'll push for the revert.
>>>
>>> So I think it's up to you now, and let's see what Gregh says about it.
>>
>> What is the current status of this?  I'd like to see this move forward so we
>> can get this fixed ASAP.
> Hi David,
>
> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
> this is applied. If it's not, I'll reping you to apply this revert. Until then,
> you can forget about it, I'll do the follow-up.
> [1] https://lkml.org/lkml/2015/2/18/310

Looping in Greg and Grant so they know we are waiting for their verdict
on that patch...


Yours,
Liunus Walleij

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Greg KH]

On Fri, Feb 20, 2015 at 10:37:59AM +0100, Linus Walleij wrote:
> On Thu, Feb 19, 2015 at 9:48 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> > David Miller <davem@davemloft.net> writes:
> >
> >>> Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
> >>> you can't make it for 3.20, I'll push for the revert.
> >>>
> >>> So I think it's up to you now, and let's see what Gregh says about it.
> >>
> >> What is the current status of this?  I'd like to see this move forward so we
> >> can get this fixed ASAP.
> > Hi David,
> >
> > Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
> > this is applied. If it's not, I'll reping you to apply this revert. Until then,
> > you can forget about it, I'll do the follow-up.
> > [1] https://lkml.org/lkml/2015/2/18/310
> 
> Looping in Greg and Grant so they know we are waiting for their verdict
> on that patch...

I have no idea what you are talking about here :(

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Linus Walleij]

On Fri, Feb 20, 2015 at 4:33 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Feb 20, 2015 at 10:37:59AM +0100, Linus Walleij wrote:
>> On Thu, Feb 19, 2015 at 9:48 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> > David Miller <davem@davemloft.net> writes:
>> >
>> >>> Now if you can make it in -rc2 or -rc3, this revert should be forgotten. But if
>> >>> you can't make it for 3.20, I'll push for the revert.
>> >>>
>> >>> So I think it's up to you now, and let's see what Gregh says about it.
>> >>
>> >> What is the current status of this?  I'd like to see this move forward so we
>> >> can get this fixed ASAP.
>> > Hi David,
>> >
>> > Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
>> > this is applied. If it's not, I'll reping you to apply this revert. Until then,
>> > you can forget about it, I'll do the follow-up.
>> > [1] https://lkml.org/lkml/2015/2/18/310
>>
>> Looping in Greg and Grant so they know we are waiting for their verdict
>> on that patch...
>
> I have no idea what you are talking about here :(

It is a patch to drivers/base, which I'm waiting for you to look at...
The link to the patch was right above, here it is again :)

https://lkml.org/lkml/2015/2/18/310

Yours,
Linus Walleij

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Robert Jarzmik]

David Miller <davem@davemloft.net> writes:

> From: Robert Jarzmik <robert.jarzmik@free.fr>
> Date: Thu, 19 Feb 2015 21:48:49 +0100
>
>> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
>> this is applied. If it's not, I'll reping you to apply this revert. Until then,
>> you can forget about it, I'll do the follow-up.
>> 
>> Does that plan sound good to you ?
>
> It sounds good to me.

Hi David,

Unfortunately Linus's patch didn't make it upstream. Therefore I'll ask you to
apply the revert, which is reminded in [1].

Cheers.

-- 
Robert

[1] Patch reminder
---<8---
From: Robert Jarzmik <robert.jarzmik@free.fr>
Subject: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"
To: Nicolas Pitre <nico@fluxnic.net>, "David S. Miller" <davem@davemloft.net>, Linus Walleij <linus.walleij@linaro.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Robert Jarzmik <robert.jarzmik@free.fr>
Date: Thu, 12 Feb 2015 17:59:10 +0100 (4 weeks, 4 days, 4 hours ago)
Message-Id: <1423760350-20149-1-git-send-email-robert.jarzmik@free.fr>
X-Mailer: git-send-email 2.1.0

The commit breaks the legacy platforms, ie. these not using device-tree,
and setting up the interrupt resources with a flag to activate edge
detection. The issue was found on the zylonite platform.

The reason is that zylonite uses platform resources to pass the interrupt number
and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to
request the irq with these flags, which in turn setups the irq as high edge
triggered.

After the patch, this was supposed to be taken care of with :
  irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));

But irq_resflags is 0 for legacy platforms, while for example in
arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the
irq flag is specified. This breaks zylonite because the interrupt is not
setup as triggered, and hardware doesn't provide interrupts.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 drivers/net/ethernet/smsc/smc91x.c | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smc91x.c b/drivers/net/ethernet/smsc/smc91x.c
index 88a55f9..5d77e6f 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -2243,10 +2243,9 @@ static int smc_drv_probe(struct platform_device *pdev)
 	const struct of_device_id *match = NULL;
 	struct smc_local *lp;
 	struct net_device *ndev;
-	struct resource *res;
+	struct resource *res, *ires;
 	unsigned int __iomem *addr;
 	unsigned long irq_flags = SMC_IRQ_FLAGS;
-	unsigned long irq_resflags;
 	int ret;
 
 	ndev = alloc_etherdev(sizeof(struct smc_local));
@@ -2338,19 +2337,16 @@ static int smc_drv_probe(struct platform_device *pdev)
 		goto out_free_netdev;
 	}
 
-	ndev->irq = platform_get_irq(pdev, 0);
-	if (ndev->irq <= 0) {
+	ires = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!ires) {
 		ret = -ENODEV;
 		goto out_release_io;
 	}
-	/*
-	 * If this platform does not specify any special irqflags, or if
-	 * the resource supplies a trigger, override the irqflags with
-	 * the trigger flags from the resource.
-	 */
-	irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq));
-	if (irq_flags == -1 || irq_resflags & IRQF_TRIGGER_MASK)
-		irq_flags = irq_resflags & IRQF_TRIGGER_MASK;
+
+	ndev->irq = ires->start;
+
+	if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK)
+		irq_flags = ires->flags & IRQF_TRIGGER_MASK;
 
 	ret = smc_request_attrib(pdev, ndev);
 	if (ret)
-- 
2.1.0

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[David Miller]

From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Mon, 16 Mar 2015 22:06:13 +0100

> David Miller <davem@davemloft.net> writes:
> 
>> From: Robert Jarzmik <robert.jarzmik@free.fr>
>> Date: Thu, 19 Feb 2015 21:48:49 +0100
>>
>>> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
>>> this is applied. If it's not, I'll reping you to apply this revert. Until then,
>>> you can forget about it, I'll do the follow-up.
>>> 
>>> Does that plan sound good to you ?
>>
>> It sounds good to me.
> 
> Hi David,
> 
> Unfortunately Linus's patch didn't make it upstream. Therefore I'll ask you to
> apply the revert, which is reminded in [1].

Revert applied, thanks.

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[Linus Walleij]

On Tue, Mar 17, 2015 at 8:05 PM, David Miller <davem@redhat.com> wrote:
> From: Robert Jarzmik <robert.jarzmik@free.fr>
> Date: Mon, 16 Mar 2015 22:06:13 +0100
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Robert Jarzmik <robert.jarzmik@free.fr>
>>> Date: Thu, 19 Feb 2015 21:48:49 +0100
>>>
>>>> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
>>>> this is applied. If it's not, I'll reping you to apply this revert. Until then,
>>>> you can forget about it, I'll do the follow-up.
>>>>
>>>> Does that plan sound good to you ?
>>>
>>> It sounds good to me.
>>
>> Hi David,
>>
>> Unfortunately Linus's patch didn't make it upstream. Therefore I'll ask you to
>> apply the revert, which is reminded in [1].
>
> Revert applied, thanks.

Since the required patch fixing the actual problem is now upstream,
can we revert the revert?

Caused by response time in maintainers, so a people problem, not
a technical one, sadly :/

Yours,
Linus Walleij

Re: [PATCH] Revert "smc91x: retrieve IRQ and trigger flags in a modern way"

[David Miller]

From: Linus Walleij <linus.walleij@linaro.org>
Date: Mon, 4 May 2015 15:18:39 +0200

> On Tue, Mar 17, 2015 at 8:05 PM, David Miller <davem@redhat.com> wrote:
>> From: Robert Jarzmik <robert.jarzmik@free.fr>
>> Date: Mon, 16 Mar 2015 22:06:13 +0100
>>
>>> David Miller <davem@davemloft.net> writes:
>>>
>>>> From: Robert Jarzmik <robert.jarzmik@free.fr>
>>>> Date: Thu, 19 Feb 2015 21:48:49 +0100
>>>>
>>>>> Linus has submitted the patch [1]. I'll be watching carefully until -rc4 that
>>>>> this is applied. If it's not, I'll reping you to apply this revert. Until then,
>>>>> you can forget about it, I'll do the follow-up.
>>>>>
>>>>> Does that plan sound good to you ?
>>>>
>>>> It sounds good to me.
>>>
>>> Hi David,
>>>
>>> Unfortunately Linus's patch didn't make it upstream. Therefore I'll ask you to
>>> apply the revert, which is reminded in [1].
>>
>> Revert applied, thanks.
> 
> Since the required patch fixing the actual problem is now upstream,
> can we revert the revert?

Ok, done.