** Patch added: "0004-Revert-UBUNTU-SAUCE-Revert-lan78xx-Correctly-indicat.patch" https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1802320/+attachment/5210384/+files/0004-Revert-UBUNTU-SAUCE-Revert-lan78xx-Correctly-indicat.patch
** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: - Correctly indicate invalid OTP"") - when doing the initial enablement of - the rpi3bp+ board in xenial, i found that the ethernet port was not - working and after a bisection i found a commit (the above "lan78xx: - Correctly indicate invalid OTP") that was causing it and i reverted it. + Correctly indicate invalid OTP""), but simply reverting that patch + uncovers another unrelated fatal problem. + + When doing the initial enablement of the rpi3bp+ board in xenial, i + found that the ethernet port was not working and after a bisection i + found a commit (the above "lan78xx: Correctly indicate invalid OTP") + that was causing it and i reverted it. But it turned out that this patch was legit, and the buggy behaviour of the lan78xx_read_otp() function it was fixing, was actually hiding another bug in the lan78xx ethernet driver - so when applied and fixed lan78xx_read_otp(), the entire lan78xx driver would completely stop stop working for another reason - after some debugging, i found what the root problem was and i explained it here in detail while asking upstream to apply a fix: https://lkml.org/lkml/2018/11/7/860 - upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here. So, to get the leds working again, we need the above fix, and get it in, we need to revert two Raspberry BSP patches, apply the upstream patch for the mac address change (that clashes with the two previous reverted patches and render them obsolete - again, see here for the detail: https://lkml.org/lkml/2018/11/7/860), and then revert the above SAUCE patch (aka apply the lan78xx_read_otp() fix). Fix: The fix consist in importing a new upstream patch from 4.18.y, reverting two Raspberry BSP patches that clash with this patch, and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing. First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan7xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch - uncovers another unrelated fatal problem. + uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i found a commit (the above "lan78xx: Correctly indicate invalid OTP") that was causing it and i reverted it. But it turned out that this patch was legit, and the buggy behaviour of the lan78xx_read_otp() function it was fixing, was actually hiding another bug in the lan78xx ethernet driver - so when applied and fixed lan78xx_read_otp(), the entire lan78xx driver would completely stop stop working for another reason - after some debugging, i found what the root problem was and i explained it here in detail while asking upstream to apply a fix: https://lkml.org/lkml/2018/11/7/860 - upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here. So, to get the leds working again, we need the above fix, and get it in, we need to revert two Raspberry BSP patches, apply the upstream patch for the mac address change (that clashes with the two previous reverted patches and render them obsolete - again, see here for the detail: https://lkml.org/lkml/2018/11/7/860), and then revert the above SAUCE patch (aka apply the lan78xx_read_otp() fix). Fix: The fix consist in importing a new upstream patch from 4.18.y, reverting two Raspberry BSP patches that clash with this patch, and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing. First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan7xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i found a commit (the above "lan78xx: Correctly indicate invalid OTP") that was causing it and i reverted it. - But it turned out that this patch was legit, and the buggy behaviour of - the lan78xx_read_otp() function it was fixing, was actually hiding + Later, it turned out that this patch was legit, and the buggy behaviour + of the lan78xx_read_otp() function it was fixing, was actually hiding another bug in the lan78xx ethernet driver - so when applied and fixed lan78xx_read_otp(), the entire lan78xx driver would completely stop stop working for another reason - after some debugging, i found what the root problem was and i explained it here in detail while asking upstream to apply a fix: https://lkml.org/lkml/2018/11/7/860 - upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here. So, to get the leds working again, we need the above fix, and get it in, we need to revert two Raspberry BSP patches, apply the upstream patch for the mac address change (that clashes with the two previous reverted patches and render them obsolete - again, see here for the detail: https://lkml.org/lkml/2018/11/7/860), and then revert the above SAUCE patch (aka apply the lan78xx_read_otp() fix). Fix: The fix consist in importing a new upstream patch from 4.18.y, reverting two Raspberry BSP patches that clash with this patch, and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing. First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan7xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i - found a commit (the above "lan78xx: Correctly indicate invalid OTP") - that was causing it and i reverted it. + found am upstream stable commit (the above "lan78xx: Correctly indicate + invalid OTP") that was causing it and i reverted it. Later, it turned out that this patch was legit, and the buggy behaviour of the lan78xx_read_otp() function it was fixing, was actually hiding another bug in the lan78xx ethernet driver - so when applied and fixed lan78xx_read_otp(), the entire lan78xx driver would completely stop stop working for another reason - after some debugging, i found what the root problem was and i explained it here in detail while asking upstream to apply a fix: https://lkml.org/lkml/2018/11/7/860 - upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here. So, to get the leds working again, we need the above fix, and get it in, we need to revert two Raspberry BSP patches, apply the upstream patch for the mac address change (that clashes with the two previous reverted patches and render them obsolete - again, see here for the detail: https://lkml.org/lkml/2018/11/7/860), and then revert the above SAUCE patch (aka apply the lan78xx_read_otp() fix). Fix: The fix consist in importing a new upstream patch from 4.18.y, reverting two Raspberry BSP patches that clash with this patch, and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing. First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan7xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i found am upstream stable commit (the above "lan78xx: Correctly indicate invalid OTP") that was causing it and i reverted it. - Later, it turned out that this patch was legit, and the buggy behaviour - of the lan78xx_read_otp() function it was fixing, was actually hiding - another bug in the lan78xx ethernet driver - so when applied and fixed - lan78xx_read_otp(), the entire lan78xx driver would completely stop stop - working for another reason - after some debugging, i found what the root - problem was and i explained it here in detail while asking upstream to - apply a fix: https://lkml.org/lkml/2018/11/7/860 - upstream later - decided to take an entire patch from 4.18.y instead of the fix i - proposed, but that is fine, and is one of the patch i'm presenting here. + But it turned out that this patch was legit, and the buggy behaviour of + the lan78xx_read_otp() function (that was being fixed by the above + "lan78xx: Correctly indicate invalid OTP") was actually hiding another + bug in the lan78xx ethernet driver. - So, to get the leds working again, we need the above fix, and get it in, - we need to revert two Raspberry BSP patches, apply the upstream patch - for the mac address change (that clashes with the two previous reverted - patches and render them obsolete - again, see here for the detail: - https://lkml.org/lkml/2018/11/7/860), and then revert the above SAUCE - patch (aka apply the lan78xx_read_otp() fix). + After some debugging, i found what the root problem was and i explained + it here in great detail, while asking upstream to apply a fix: + + https://lkml.org/lkml/2018/11/7/860 + + Upstream later decided to take an entire patch from 4.18.y instead of + the fix i proposed, but that is fine, and is one of the patch i'm + presenting here (patch 003 "lan78xx: Read MAC address from DT if + present"). Fix: - The fix consist in importing a new upstream patch from 4.18.y, reverting - two Raspberry BSP patches that clash with this patch, and then reverting - a SAUCE patch, or in other words, reapply the fix this SAUCE patch was - removing. + The whole fix consist in importing a new upstream patch from 4.18.y + (patch 003), reverting two Raspberry BSP patches that clash with this + patch (patch 001 and 002), and then reverting a SAUCE patch, or in other + words, reapply the fix this SAUCE patch was removing (patch 004). First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac - change feature of the lan7xx driver: + change feature of the lan78xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i - found am upstream stable commit (the above "lan78xx: Correctly indicate + found an upstream stable commit (the above "lan78xx: Correctly indicate invalid OTP") that was causing it and i reverted it. But it turned out that this patch was legit, and the buggy behaviour of the lan78xx_read_otp() function (that was being fixed by the above "lan78xx: Correctly indicate invalid OTP") was actually hiding another bug in the lan78xx ethernet driver. After some debugging, i found what the root problem was and i explained it here in great detail, while asking upstream to apply a fix: https://lkml.org/lkml/2018/11/7/860 Upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here (patch 003 "lan78xx: Read MAC address from DT if present"). Fix: The whole fix consist in importing a new upstream patch from 4.18.y (patch 003), reverting two Raspberry BSP patches that clash with this patch (patch 001 and 002), and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing (patch 004). First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan78xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. ** Description changed: Impact: Using a xenial/raspi2 kernel on a RaspberryPi3B+ board, ethernet leds don't blink (though ethernet port works fine). Leds not working are due to a missing (actualy reverted) upstream stable patch in xenial/raspi2 (1111a9 "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP""), but simply reverting that patch uncovers another, unrelated, fatal problem. When doing the initial enablement of the rpi3bp+ board in xenial, i found that the ethernet port was not working and after a bisection i found an upstream stable commit (the above "lan78xx: Correctly indicate invalid OTP") that was causing it and i reverted it. But it turned out that this patch was legit, and the buggy behaviour of the lan78xx_read_otp() function (that was being fixed by the above "lan78xx: Correctly indicate invalid OTP") was actually hiding another bug in the lan78xx ethernet driver. After some debugging, i found what the root problem was and i explained - it here in great detail, while asking upstream to apply a fix: + it here in great detail, while asking upstream to apply a fix for all + the stable trees: https://lkml.org/lkml/2018/11/7/860 Upstream later decided to take an entire patch from 4.18.y instead of the fix i proposed, but that is fine, and is one of the patch i'm presenting here (patch 003 "lan78xx: Read MAC address from DT if present"). Fix: The whole fix consist in importing a new upstream patch from 4.18.y (patch 003), reverting two Raspberry BSP patches that clash with this patch (patch 001 and 002), and then reverting a SAUCE patch, or in other words, reapply the fix this SAUCE patch was removing (patch 004). First the two reverts: commit 3f25fbb82f00a80e9eb3be0ce60abebfc263c84a Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:09 2018 +0000 Revert "lan78xx: Ignore DT MAC address if already valid" This reverts commit 17f23a96597810ddd56b0c10584fce77d7c3707f. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and commit 6c8bdff882656296adc20b6ae0fb727483a73c7c Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:35:11 2018 +0000 Revert "lan78xx: Read MAC address from DT if present" This reverts commit a23d928781936b51a61a67a0799b77b2a6becfa2. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and substitute these two with an upstream cherry pick that fix the mac change feature of the lan78xx driver: commit 5d9c81e3aa1dd39dafd9a6ea30da05b26b655eca Author: Phil Elwell <p...@raspberrypi.org> Date: Thu Apr 19 17:59:38 2018 +0100 lan78xx: Read MAC address from DT if present There is a standard mechanism for locating and using a MAC address from the Device Tree. Use this facility in the lan78xx driver to support applications without programmed EEPROM or OTP. At the same time, regularise the handling of the different address sources. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Signed-off-by: David S. Miller <da...@davemloft.net> (cherry picked from commit 760db29bdc97b73ff60b091315ad787b1deb5cf5) Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> and finally revert the SAUCE patch that will make the led code work again: commit 24dc8f22b15cc983e13a0ae88b372dd1bfad09f9 Author: Paolo Pisati <paolo.pis...@canonical.com> Date: Thu Nov 8 10:37:17 2018 +0000 Revert "UBUNTU: SAUCE: Revert "lan78xx: Correctly indicate invalid OTP"" This reverts commit 1111a9e0bd2ebab88e736d8a9773df2ec76dc52c. Signed-off-by: Paolo Pisati <paolo.pis...@canonical.com> See also the attached patches. How to test: Boot a patched kernel, connect an ethernet cable to the board and check that the ethernet leds are blinking when there's traffic Regression potential: None, we are dropping two raspberry BSP patches in favor of an upstream fix and re-applying another upstream fix: all patches have been upstream for awhile, and are clean cherry picks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1802320 Title: rpi3bp+: ethernet leds don't blink To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1802320/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
