Re: mv88e6321, dual cpu port

From: Vladimir Oltean <olteanv@gmail.com>
To: Angelo Dureghello <angelo@kernel-space.org>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev@vger.kernel.org
Subject: Re: mv88e6321, dual cpu port
Date: Mon, 23 Jan 2023 21:18:44 +0200	[thread overview]
Message-ID: <20230123191844.ltcm7ez5yxhismos@skbuf> (raw)
In-Reply-To: <7e29d955-2673-ea54-facb-3f96ce027e96@kernel-space.org>

On Mon, Jan 23, 2023 at 02:26:55PM +0100, Angelo Dureghello wrote:
> Hi Vladimir,
> 
> On Mon, 23 Jan 2023, Vladimir Oltean wrote:
> 
> > On Mon, Jan 23, 2023 at 09:52:15AM +0100, Angelo Dureghello wrote:
> > > I am now stuck to 5.4.70 due to freescale stuff in it.
> > > I tried shortly a downgrade of net/dsa part from 5.5,
> > > but, even if i have no errors, i can't ping out, something
> > > seems has gone wrong, i don't like too much this approach.
> > > 
> > > But of course, i could upgrade to 5.10 that's available
> > > from freescale, with some effort.
> > > Then, i still should apply a patch on the driver to have dual
> > > cpu running, if i understand properly, correct ?
> > 
> > What is the Freescale chip stuck on 5.4 (5.10 with some effort) if I may
> > ask? I got the impression that the vast majority of SoCs have good
> > enough mainline support to boot a development kernel and work on that,
> > the exception being some S32 platforms.
> > 
> 
> I think i tested mainline kernel, but the rpmsg part to
> communicate with M4 core and scu firmware seems not there.
> So i am stuck with freescale stuff now. Anyway, freescale
> released their 5.10 branch, so eventually i'll move
> to that.

Ok, SC firmware isn't something that I'd be able to assist with.
Isn't there a 5.15 kernel currently available too?
https://github.com/nxp-imx/linux-imx/tree/lf-5.15.y
And I guess a kernel based on 6.1 should become publicly available
soon too (your FAE should probably be able to say more).

The point is that multi-CPU-port support for mv88e6xxx isn't present in
the mainline kernel, no matter what kernel version we're talking about.
And even if you plan on adding this support yourself, doing so on a very
old kernel is a waste of time, because you won't be able to backport DSA
in a way in which the backported code base is similar enough to what's
upstream (and not to mention, behaves similarly enough).

I don't know what this means:

| I am now trying this way on mv88e6321,
| - one vlan using dsa kernel driver,
| - other vlan using dsdt userspace driver.

specifically what is "dsdt userspace driver".