From: <gregkh@linuxfoundation.org>
To: Bogdan-Stefan_Mirea@mentor.com, alexander.levin@verizon.com,
gregkh@linuxfoundation.org, horms+renesas@verge.net.au,
vladimir_zapolskiy@mentor.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property" has been added to the 4.14-stable tree
Date: Wed, 28 Feb 2018 16:25:27 +0100 [thread overview]
Message-ID: <15198315273084@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:23:28 CET 2018
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Date: Thu, 21 Dec 2017 17:18:59 +0200
Subject: arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
[ Upstream commit 7d2901f809c110bd9a261e879d59efe62e3bc758 ]
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
Patches currently in stable-queue which might be from Bogdan-Stefan_Mirea@mentor.com are
queue-4.14/arm64-dts-renesas-ulcb-remove-renesas-no-ether-link-property.patch
reply other threads:[~2018-02-28 15:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=15198315273084@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Bogdan-Stefan_Mirea@mentor.com \
--cc=alexander.levin@verizon.com \
--cc=horms+renesas@verge.net.au \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=vladimir_zapolskiy@mentor.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: 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.