Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Fill in STU support for all
 supported chips
From:   patchwork-bot+netdevbpf@kernel.org
Message-Id: <164790721066.15202.17830576160916908515.git-patchwork-notify@kernel.org>
Date:   Tue, 22 Mar 2022 00:00:10 +0000
References: <20220319110345.555270-1-tobias@waldekranz.com>
In-Reply-To: <20220319110345.555270-1-tobias@waldekranz.com>
To:     Tobias Waldekranz <tobias@waldekranz.com>
Cc:     davem@davemloft.net, kuba@kernel.org, kabel@kernel.org,
        andrew@lunn.ch, vivien.didelot@gmail.com, f.fainelli@gmail.com,
        olteanv@gmail.com, pabeni@redhat.com, linux@armlinux.org.uk,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Precedence: bulk

Hello:

This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:

On Sat, 19 Mar 2022 12:03:45 +0100 you wrote:
> Some chips using the split VTU/STU design will not accept VTU entries
> who's SID points to an invalid STU entry. Therefore, mark all those
> chips with either the mv88e6352_g1_stu_* or mv88e6390_g1_stu_* ops as
> appropriate.
> 
> Notably, chips for the Opal Plus (6085/6097) era seem to use a
> different implementation than those from Agate (6352) and onwards,
> even though their external interface is the same. The former happily
> accepts VTU entries referencing invalid STU entries, while the latter
> does not.
> 
> [...]

Here is the summary with links:
  - [net-next] net: dsa: mv88e6xxx: Fill in STU support for all supported chips
    https://git.kernel.org/netdev/net-next/c/c050f5e91b47

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html