All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jordan Vrtanoski <jordan.vrtanoski@gmail.com>, stable@vger.kernel.org
Cc: mw@semihalf.com, linux-arm-kernel@lists.infradead.org,
	stefanc@marvell.com
Subject: Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150
Date: Mon, 22 Nov 2021 19:53:44 +0000	[thread overview]
Message-ID: <YZv1SBrYTXmorcLJ@shell.armlinux.org.uk> (raw)
In-Reply-To: <2F6C75BF-6CD8-4A58-B8AA-4D3A6B5A1008@gmail.com>

On Mon, Nov 22, 2021 at 02:51:36PM +0400, Jordan Vrtanoski wrote:
> Hi,
>     After bisecting, the regression defect was introduced in 5.4.90 with the following patch:
> "[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”
> 
>     The patch is changing the configuration of the port during the initialisation of MVPP22_XLG_CTRL0_REG, which
> on ClearFog GT 8K is preventing the MVPP2 to properly start the MAC after the transceiver is detected. After reverting 
> the patch, the transceiver works properly.

Right, the problem will be 875082244853 ("net: mvpp2: disable force
link UP during port init procedure") that has been backported to
kernels that it shouldn't have been applied to.

There is a subtle interaction between that commit and development work
leading up to it that wasn't obvious during the review. Specifically,
any kernel without fefeae73ac7a ("net: mvpp2: ensure the port is forced
down while changing modes") will now be broken.

However, fefeae73ac7a is development work, and so can't be backported.

Adding stable to this thread so they're aware of the issue.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jordan Vrtanoski <jordan.vrtanoski@gmail.com>, stable@vger.kernel.org
Cc: mw@semihalf.com, linux-arm-kernel@lists.infradead.org,
	stefanc@marvell.com
Subject: Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150
Date: Mon, 22 Nov 2021 19:53:44 +0000	[thread overview]
Message-ID: <YZv1SBrYTXmorcLJ@shell.armlinux.org.uk> (raw)
In-Reply-To: <2F6C75BF-6CD8-4A58-B8AA-4D3A6B5A1008@gmail.com>

On Mon, Nov 22, 2021 at 02:51:36PM +0400, Jordan Vrtanoski wrote:
> Hi,
>     After bisecting, the regression defect was introduced in 5.4.90 with the following patch:
> "[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”
> 
>     The patch is changing the configuration of the port during the initialisation of MVPP22_XLG_CTRL0_REG, which
> on ClearFog GT 8K is preventing the MVPP2 to properly start the MAC after the transceiver is detected. After reverting 
> the patch, the transceiver works properly.

Right, the problem will be 875082244853 ("net: mvpp2: disable force
link UP during port init procedure") that has been backported to
kernels that it shouldn't have been applied to.

There is a subtle interaction between that commit and development work
leading up to it that wasn't obvious during the review. Specifically,
any kernel without fefeae73ac7a ("net: mvpp2: ensure the port is forced
down while changing modes") will now be broken.

However, fefeae73ac7a is development work, and so can't be backported.

Adding stable to this thread so they're aware of the issue.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-11-22 19:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 10:11 ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150 Jordan Vrtanoski
2021-11-16 10:51 ` Russell King (Oracle)
2021-11-20 18:57   ` Jordan Vrtanoski
2021-11-20 19:41     ` Russell King (Oracle)
2021-11-21  5:37       ` Jordan Vrtanoski
2021-11-22 10:51         ` Jordan Vrtanoski
2021-11-22 13:15           ` Jordan Vrtanoski
2021-11-22 19:53           ` Russell King (Oracle) [this message]
2021-11-22 19:53             ` Russell King (Oracle)
2021-11-23 12:20             ` Greg KH
2021-11-23 12:20               ` Greg KH

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=YZv1SBrYTXmorcLJ@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=jordan.vrtanoski@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mw@semihalf.com \
    --cc=stable@vger.kernel.org \
    --cc=stefanc@marvell.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.