linux-kernel - Re: [PATCH net-next v13 01/13] rtase: Add pci table supported in this module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231202105845.12e27e31@kernel.org>
Date:   Sat, 2 Dec 2023 10:58:45 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Justin Lai <justinlai0215@...ltek.com>, davem@...emloft.net,
        edumazet@...gle.com, pabeni@...hat.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        pkshih@...ltek.com, larry.chiu@...ltek.com
Subject: Re: [PATCH net-next v13 01/13] rtase: Add pci table supported in
 this module

On Sat, 2 Dec 2023 17:27:57 +0100 Andrew Lunn wrote:
> > > + *  The block of the Realtek RTL90xx series is our entire chip architecture,
> > > + *  the GMAC is connected to the switch core, and there is no PHY in between.
> > > + *  In addition, this driver is mainly used to control GMAC, but does not
> > > + *  control the switch core, so it is not the same as DSA.  
> > 
> > Okay, but you seem to only register one netdev.
> > 
> > Which MAC is it for?  
> 
> The GMAC one. This is going to be a DSA system, and this driver is for
> the conduit MAC the CPU uses. At some point, i hope there is a DSA
> driver added, or the existing realtek driver is extended to support
> this switch.

Oh, thanks, it even says so in the comment. I blame it on late night
reviewing. I was confused by the "driver [...] does not control the
switch core, so it is not the same as DSA." Looking at the discussion
in v3 it sounds like the switch is controlled by a different PCI
function? In which case it very much sounds like DSA. Or maybe there
was a minor misunderstanding there, and the driver will need MFD /
auxbus, which is still close to DSA.

I'm mainly asking to make sure we avoid "implicitly programming" the
switch, like, IIUC, one of the TI drivers did. And we ended up with
multiple versions / modes of operation :( Sounds like this driver
doesn't touch switch registers yet, tho, so all good.