[meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11


Quentin Schulz
 

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
...-rk-Fix-ethernet-on-rk3399-based-dev.patch | 63 +++++++++++++++++++
.../linux/linux-yocto/5.14-rk3399-mac-fix.scc | 1 +
.../linux/linux-yocto_5.14.bbappend | 11 ++++
3 files changed, 75 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
create mode 100644 recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
create mode 100644 recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
new file mode 100644
index 0000000..b2ce7e8
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
@@ -0,0 +1,63 @@
+From 8efe947ea1eace444d78398a31469b30e47ae585 Mon Sep 17 00:00:00 2001
+From: Punit Agrawal <punitagrawal@...>
+Date: Wed, 29 Sep 2021 22:50:49 +0900
+Subject: [PATCH] net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devices
+
+[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ]
+
+Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+while getting rid of a runtime PM warning ended up breaking ethernet
+on rk3399 based devices. By dropping an extra reference to the device,
+the commit ends up enabling suspend / resume of the ethernet device -
+which appears to be broken.
+
+While the issue with runtime pm is being investigated, partially
+revert commit 2d26f6e39afb to restore the network on rk3399.
+
+Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+Suggested-by: Heiko Stuebner <heiko@...>
+Signed-off-by: Punit Agrawal <punitagrawal@...>
+Cc: Michael Riesch <michael.riesch@...>
+Tested-by: Heiko Stuebner <heiko@...>
+Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@...>
+Signed-off-by: Sasha Levin <sashal@...>
+
+Upstream-Status: Backport [8efe947ea1eace444d78398a31469b30e47ae585]
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+index ed817011a94a..6924a6aacbd5 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+@@ -21,6 +21,7 @@
+ #include <linux/delay.h>
+ #include <linux/mfd/syscon.h>
+ #include <linux/regmap.h>
++#include <linux/pm_runtime.h>
+
+ #include "stmmac_platform.h"
+
+@@ -1528,6 +1529,8 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
+ return ret;
+ }
+
++ pm_runtime_get_sync(dev);
++
+ if (bsp_priv->integrated_phy)
+ rk_gmac_integrated_phy_powerup(bsp_priv);
+
+@@ -1539,6 +1542,8 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac)
+ if (gmac->integrated_phy)
+ rk_gmac_integrated_phy_powerdown(gmac);
+
++ pm_runtime_put_sync(&gmac->pdev->dev);
++
+ phy_power_on(gmac, false);
+ gmac_clk_enable(gmac, false);
+ }
+--
+2.33.1
+
diff --git a/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
new file mode 100644
index 0000000..1ad2bde
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
@@ -0,0 +1 @@
+patch 0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
diff --git a/recipes-kernel/linux/linux-yocto_5.14.bbappend b/recipes-kernel/linux/linux-yocto_5.14.bbappend
new file mode 100644
index 0000000..5eaa604
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.14.bbappend
@@ -0,0 +1,11 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+
+# Fix Ethernet on 5.14 until 5.14.11 (included) for RK3399 MAC controller
+# Conditional patching required because Honister 3.4 has linux-yocto
+# v5.14.9 and Honister 3.4.1 will have at least linux-yocto v5.14.14.
+python __anonymous() {
+ kver = d.getVar('LINUX_VERSION') or ''
+ if bb.utils.is_semver(kver) \
+ and bb.utils.vercmp_string(kver, '5.14.11') <= 0:
+ d.appendVar('SRC_URI', ' file://5.14-rk3399-mac-fix.scc')
+}
--
2.30.2


Khem Raj
 

On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4


Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
...-rk-Fix-ethernet-on-rk3399-based-dev.patch | 63 +++++++++++++++++++
.../linux/linux-yocto/5.14-rk3399-mac-fix.scc | 1 +
.../linux/linux-yocto_5.14.bbappend | 11 ++++
3 files changed, 75 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
create mode 100644 recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
create mode 100644 recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
new file mode 100644
index 0000000..b2ce7e8
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
@@ -0,0 +1,63 @@
+From 8efe947ea1eace444d78398a31469b30e47ae585 Mon Sep 17 00:00:00 2001
+From: Punit Agrawal <punitagrawal@...>
+Date: Wed, 29 Sep 2021 22:50:49 +0900
+Subject: [PATCH] net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devices
+
+[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ]
+
+Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+while getting rid of a runtime PM warning ended up breaking ethernet
+on rk3399 based devices. By dropping an extra reference to the device,
+the commit ends up enabling suspend / resume of the ethernet device -
+which appears to be broken.
+
+While the issue with runtime pm is being investigated, partially
+revert commit 2d26f6e39afb to restore the network on rk3399.
+
+Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+Suggested-by: Heiko Stuebner <heiko@...>
+Signed-off-by: Punit Agrawal <punitagrawal@...>
+Cc: Michael Riesch <michael.riesch@...>
+Tested-by: Heiko Stuebner <heiko@...>
+Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@...>
+Signed-off-by: Sasha Levin <sashal@...>
+
+Upstream-Status: Backport [8efe947ea1eace444d78398a31469b30e47ae585]
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+index ed817011a94a..6924a6aacbd5 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+@@ -21,6 +21,7 @@
+ #include <linux/delay.h>
+ #include <linux/mfd/syscon.h>
+ #include <linux/regmap.h>
++#include <linux/pm_runtime.h>
+
+ #include "stmmac_platform.h"
+
+@@ -1528,6 +1529,8 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
+ return ret;
+ }
+
++ pm_runtime_get_sync(dev);
++
+ if (bsp_priv->integrated_phy)
+ rk_gmac_integrated_phy_powerup(bsp_priv);
+
+@@ -1539,6 +1542,8 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac)
+ if (gmac->integrated_phy)
+ rk_gmac_integrated_phy_powerdown(gmac);
+
++ pm_runtime_put_sync(&gmac->pdev->dev);
++
+ phy_power_on(gmac, false);
+ gmac_clk_enable(gmac, false);
+ }
+--
+2.33.1
+
diff --git a/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
new file mode 100644
index 0000000..1ad2bde
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
@@ -0,0 +1 @@
+patch 0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
diff --git a/recipes-kernel/linux/linux-yocto_5.14.bbappend b/recipes-kernel/linux/linux-yocto_5.14.bbappend
new file mode 100644
index 0000000..5eaa604
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.14.bbappend
@@ -0,0 +1,11 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+
+# Fix Ethernet on 5.14 until 5.14.11 (included) for RK3399 MAC controller
+# Conditional patching required because Honister 3.4 has linux-yocto
+# v5.14.9 and Honister 3.4.1 will have at least linux-yocto v5.14.14.
+python __anonymous() {
+ kver = d.getVar('LINUX_VERSION') or ''
+ if bb.utils.is_semver(kver) \
+ and bb.utils.vercmp_string(kver, '5.14.11') <= 0:
+ d.appendVar('SRC_URI', ' file://5.14-rk3399-mac-fix.scc')
+}
--
2.30.2




Khem Raj
 

On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?


Cheers,
Quentin


Khem Raj
 



On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <quentin.schulz@...> wrote:
On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
> On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
> <quentin.schulz@...> wrote:
> >
> > On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
> > > On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
> > > <quentin.schulz@...> wrote:
> > > >
> > > > From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
> > > > controller found on RK3399 is not working.
> > > >
> > > > A fix is available in v5.14.12 and later (available also in v5.15)
> > > > which is provided here and applied to linux-yocto source tree if
> > > > linux-yocto version is of the impacted ones.
> > > >
> > > > The conditional patching is unfortunately required because Honister 3.4
> > > > has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
> > > > linux-yocto v5.14.14.
> > >
> > > Patching piece below looks quite a bit.
> > > lets just fix v5.14.14 and dont worry about 3.4
> > >
> >
> > v5.14.14 is already fixed. The only release currently is 3.4 and I hit
> > that issue, hence the patch.
> > I assume not everybody is updating to 3.4.1 when it's out, I've seen
> > people running behind dot releases.
> > What's bothering you?
>
> once dot release is out then thats whats maintained not the original
> release since they are incremental.
> the anon python to apply a patch. Can you explain why we want to patch
> applied this way ?
>

I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch 


Cheers,
Quentin


Quentin Schulz
 

On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?

meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.

Cheers
Quentin


Cheers,
Quentin


Khem Raj
 

On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
Update to latest honister branch or wait for 3.4.1, would be my suggestion.


Cheers
Quentin


Cheers,
Quentin


Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?

Cheers,
Quentin


Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

Cheers,
Quentin


Quentin Schulz
 

Hi Khem,

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.
meta-rockchip does not have a honister branch for now because it is
still working with master branch from OE-Core. This patch does not break
this behaviour.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
Do I add a "known issues" to the README then? Or where am I supposed to
add this piece of information were this patch not merged?

if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.
I think we both understand each other's stance and I've no additional
arguments to give, so it'll be up to the maintainer(s) which is
officially Trevor, but maybe I am not aware of other unofficial
maintainers :)

In any case, I can have this patch in my own vendor BSP but since it
applies to all RK3399-based devices, I thought it'd be nicer to have it
in upstream meta-rockchip than in a vendor BSP unrelated to the boards
one's using.

@Trevor/maintainers, let us know what's your opinion on this so I know
if I should send a v2 using inline python function for SRC_URI instead
of using the anonymous python function.

Cheers,
Quentin


Khem Raj
 



On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <quentin.schulz@...> wrote:
Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less of a problem. Version specific patching will set a different preset for the layer to carry unexcercised patches



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
> On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:
> >
> >
> >
> > On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
> > >On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
> > >quentin.schulz@...> wrote:
> > >
> > >> On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
> > >> > On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
> > >> > <quentin.schulz@...> wrote:
> > >> > >
> > >> > > On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
> > >> > > > On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
> > >> > > > <quentin.schulz@...> wrote:
> > >> > > > >
> > >> > > > > From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
> > >> MAC
> > >> > > > > controller found on RK3399 is not working.
> > >> > > > >
> > >> > > > > A fix is available in v5.14.12 and later (available also in v5.15)
> > >> > > > > which is provided here and applied to linux-yocto source tree if
> > >> > > > > linux-yocto version is of the impacted ones.
> > >> > > > >
> > >> > > > > The conditional patching is unfortunately required because
> > >> Honister 3.4
> > >> > > > > has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
> > >> > > > > linux-yocto v5.14.14.
> > >> > > >
> > >> > > > Patching piece below looks quite a bit.
> > >> > > > lets just fix v5.14.14 and dont worry about 3.4
> > >> > > >
> > >> > >
> > >> > > v5.14.14 is already fixed. The only release currently is 3.4 and I hit
> > >> > > that issue, hence the patch.
> > >> > > I assume not everybody is updating to 3.4.1 when it's out, I've seen
> > >> > > people running behind dot releases.
> > >> > > What's bothering you?
> > >> >
> > >> > once dot release is out then thats whats maintained not the original
> > >> > release since they are incremental.
> > >> > the anon python to apply a patch. Can you explain why we want to patch
> > >> > applied this way ?
> > >> >
> > >>
> > >> I could define a python function and use it like this:
> > >> SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"
> > >>
> > >> Would that work better for you?
> > >
> > >
> > >I am not yet convinced why should we have such version specific patch
> > >
> >
> > If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.
> >
> > Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
>
> meta-rockchip does not have honister branch for now. So it expects
> master to keep working with honister for now. kernel upgrades are
> already committed into honister branch on meta-yocto-bsps so fix it
> already available in latest honister
> branch and will be in imminent point release soon as well.
>
> >
> > meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?
> >
> > Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
> >
>
> I would say yes, document it as that of a known issue and possible fix
> if someone is using exact point release. They might have snapshotted
> meta-rockpi too and in that case it will be easy for them to carry a
> local patch if needed.
> vesion specific patching would also be setting a not so desired
> patching practice, so I am trying to avoid it if we can.
>
> > I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
>
> Update to latest honister branch or wait for 3.4.1, would be my suggestion.
>
> >
> > Cheers
> > Quentin
> > >>
> > >>
> > >> Cheers,
> > >> Quentin
> > >>


Quentin Schulz
 

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches
We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.

Cheers,
Quentin



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <
raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the
Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in
v5.15)
which is provided here and applied to linux-yocto source
tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at
least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4
and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've
seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the
original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to
patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to
find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the
latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not
there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to
people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this
patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my
suggestion.


Cheers
Quentin


Cheers,
Quentin


Khem Raj
 

On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches
We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.
I agree with you that broken is not good as it was for sometime, but
now with the latest supported release in 3.4 series ( which is 3.4.1)
things should be good.


Cheers,
Quentin



Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <
raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the
Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in
v5.15)
which is provided here and applied to linux-yocto source
tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at
least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4
and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've
seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the
original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to
patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to
find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the
latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not
there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to
people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this
patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my
suggestion.


Cheers
Quentin


Cheers,
Quentin


Trevor Woerner
 

Hi Quentin/Khem,

On Mon 2021-12-13 @ 09:35:53 AM, Khem Raj wrote:
On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)
I apologize for not reviewing this patch in a timely manner; I'm sorry for the
frustration it caused.

Would this have been solved by (me) creating a honister branch? I usually
don't create a release branch until openembedded-core moves, but this looks
like it was a case where master and the latest branch diverged?

If so, would that still be useful?

Best regards,
Trevor


Quentin Schulz
 

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
Update to latest honister branch or wait for 3.4.1, would be my suggestion.


Cheers
Quentin


Cheers,
Quentin


Quentin Schulz
 

Hi all,

On Mon, Dec 13, 2021 at 05:30:05PM -0500, Trevor Woerner wrote:
Hi Quentin/Khem,

On Mon 2021-12-13 @ 09:35:53 AM, Khem Raj wrote:
On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)
I apologize for not reviewing this patch in a timely manner; I'm sorry for the
frustration it caused.
No frustration on my side, just a debate/discussion on what we should
do.

Would this have been solved by (me) creating a honister branch? I usually
No, the problem is the same because it is broken only in Honister 3.4.
So if we take this patch in, we basically have some code only for
"patching" honister 3.4 but anything different than that, the patch is
not necessary. So with a honister branch the "problem" stays the same.

The question is more what's the policy with that kind of patch. Would
you be ok taking that kind of patch which applies only to one dot
release of Yocto and nothing else? Or do we just ignore it until the
next dot release so it's fixed? Also do we expect to support honister
3.4 or once 3.4.1 is out (it is), we decide 3.4 is not supported at all?

I'd like at least to mention somewhere that meta-rockchip is supposed to
be used with something different than honister 3.4.

Anyway, it's ok not to answer now and hope a similar issue does not
happen later, or this discussion will be brought up again :)

Cheers,
Quentin