From: Andrew Lunn <andrew@lunn.ch>
To: "Marek Behún" <kabel@kernel.org>
Cc: "Gregory CLEMENT" <gregory.clement@bootlin.com>,
"Rui Salvaterra" <rsalvaterra@gmail.com>,
"Uwe Kleine-König" <uwe@kleine-koenig.org>,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH mvebu-dt] ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
Date: Sun, 21 Feb 2021 01:10:57 +0100 [thread overview]
Message-ID: <YDGlESUA6pOAm9JL@lunn.ch> (raw)
In-Reply-To: <20210220231144.32325-1-kabel@kernel.org>
On Sun, Feb 21, 2021 at 12:11:44AM +0100, Marek Behún wrote:
> Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
> of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.
>
> Without this the pin is by default in LED[2] mode, and the Marvell PHY
> driver configures LED[2] into "On - Link, Blink - Activity" mode.
>
> This fixes the issue where the pca9538 GPIO/interrupt controller (which
> can't mask interrupts in HW) received too many interrupts and after a
> time started ignoring the interrupt with error message:
> IRQ 71: nobody cared
Hi Marek
The pca9538 and alike are a poor choice for interrupts. As you said,
you cannot mask interrupts, and input are interrupt sources.
With this change, does it actually work reliably? It looks like all
the inputs you have support polling. And because this devices is so
unreliable with interrupts, interrupt support is mostly not built. I
would not expect a distribution kernel to enable interrupt support for
this driver. Does all the code correctly fall back to polling when
interrupts are not available?
So although the patch looks O.K, i'm just wonder if it is worth it, or
the better fix is to remove the interrupt configuration from the
pca9538 node.
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: "Marek Behún" <kabel@kernel.org>
Cc: stable@vger.kernel.org,
"Gregory CLEMENT" <gregory.clement@bootlin.com>,
linux-arm-kernel@lists.infradead.org,
"Uwe Kleine-König" <uwe@kleine-koenig.org>,
"Rui Salvaterra" <rsalvaterra@gmail.com>
Subject: Re: [PATCH mvebu-dt] ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin
Date: Sun, 21 Feb 2021 01:10:57 +0100 [thread overview]
Message-ID: <YDGlESUA6pOAm9JL@lunn.ch> (raw)
In-Reply-To: <20210220231144.32325-1-kabel@kernel.org>
On Sun, Feb 21, 2021 at 12:11:44AM +0100, Marek Behún wrote:
> Use the `marvell,reg-init` DT property to configure the LED[2]/INTn pin
> of the Marvell 88E1514 ethernet PHY on Turris Omnia into interrupt mode.
>
> Without this the pin is by default in LED[2] mode, and the Marvell PHY
> driver configures LED[2] into "On - Link, Blink - Activity" mode.
>
> This fixes the issue where the pca9538 GPIO/interrupt controller (which
> can't mask interrupts in HW) received too many interrupts and after a
> time started ignoring the interrupt with error message:
> IRQ 71: nobody cared
Hi Marek
The pca9538 and alike are a poor choice for interrupts. As you said,
you cannot mask interrupts, and input are interrupt sources.
With this change, does it actually work reliably? It looks like all
the inputs you have support polling. And because this devices is so
unreliable with interrupts, interrupt support is mostly not built. I
would not expect a distribution kernel to enable interrupt support for
this driver. Does all the code correctly fall back to polling when
interrupts are not available?
So although the patch looks O.K, i'm just wonder if it is worth it, or
the better fix is to remove the interrupt configuration from the
pca9538 node.
Andrew
_______________________________________________
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-02-21 0:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-20 23:11 [PATCH mvebu-dt] ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin Marek Behún
2021-02-20 23:11 ` Marek Behún
2021-02-21 0:10 ` Andrew Lunn [this message]
2021-02-21 0:10 ` Andrew Lunn
2021-02-21 0:47 ` Marek Behún
2021-02-21 0:47 ` Marek Behún
2021-02-21 21:18 ` Andrew Lunn
2021-02-21 21:18 ` Andrew Lunn
2021-02-21 22:40 ` Marek Behún
2021-02-21 22:40 ` Marek Behún
2021-02-21 19:58 ` Rui Salvaterra
2021-02-21 19:58 ` Rui Salvaterra
2021-02-21 20:52 ` Andrew Lunn
2021-02-21 20:52 ` Andrew Lunn
2021-02-21 20:58 ` Marek Behún
2021-02-21 20:58 ` Marek Behún
2021-04-02 20:15 ` Gregory CLEMENT
2021-04-02 20:15 ` Gregory CLEMENT
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=YDGlESUA6pOAm9JL@lunn.ch \
--to=andrew@lunn.ch \
--cc=gregory.clement@bootlin.com \
--cc=kabel@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=rsalvaterra@gmail.com \
--cc=stable@vger.kernel.org \
--cc=uwe@kleine-koenig.org \
/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: link
Be 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.