[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230517161657.a6ej5z53qicqe5aj@skbuf>
Date: Wed, 17 May 2023 19:16:57 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Arınç ÜNAL <arinc.unal@...nc9.com>
Cc: Frank Wunderlich <frank-w@...lic-files.de>,
Felix Fietkau <nbd@....name>, netdev <netdev@...r.kernel.org>,
erkin.bozoglu@...ont.com, Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
John Crispin <john@...ozen.org>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Landen Chao <Landen.Chao@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
DENG Qingfang <dqfext@...il.com>
Subject: Re: Choose a default DSA CPU port
On Wed, May 17, 2023 at 07:14:01PM +0300, Arınç ÜNAL wrote:
> On 17.05.2023 19:10, Vladimir Oltean wrote:
> > On Tue, May 16, 2023 at 10:29:27PM +0300, Arınç ÜNAL wrote:
> > > For MT7530, the port to trap the frames to is fixed since CPU_PORT is only
> > > of 3 bits so only one CPU port can be defined. This means that, in case of
> > > multiple ports used as CPU ports, any frames set for trapping to CPU port
> > > will be trapped to the numerically greatest CPU port.
> >
> > *that is up
>
> Yes, the DSA conduit interface of the CPU port must be up. Otherwise, these
> frames won't appear anywhere. I should mention this on my patch, thanks.
Well, mentioning it in the patch or in a comment is likely not going to
be enough. You likely have to implement ds->ops->master_state_change()
and update the MT7530_MFC register to a value that is always valid when
the conduit interfaces come and go.
Powered by blists - more mailing lists