Re: [net-next PATCH v4 04/13] drivers: net: dsa: qca8k: add support for cpu port 6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 10, 2021 at 03:22:49PM +0200, Ansuel Smith wrote:
> On Sun, Oct 10, 2021 at 03:42:43PM +0300, Vladimir Oltean wrote:
> > On Sun, Oct 10, 2021 at 01:15:47PM +0200, Ansuel Smith wrote:
> > > Currently CPU port is always hardcoded to port 0. This switch have 2 CPU
> > > port. The original intention of this driver seems to be use the
> > > mac06_exchange bit to swap MAC0 with MAC6 in the strange configuration
> > > where device have connected only the CPU port 6. To skip the
> > > introduction of a new binding, rework the driver to address the
> > > secondary CPU port as primary and drop any reference of hardcoded port.
> > > With configuration of mac06 exchange, just skip the definition of port0
> > > and define the CPU port as a secondary. The driver will autoconfigure
> > > the switch to use that as the primary CPU port.
...
> > If I were to trust the documentation, that DSA headers are enabled on
> > port 0 when the driver does this:
> > 
> > 	/* Enable CPU Port */
> > 	ret = qca8k_reg_set(priv, QCA8K_REG_GLOBAL_FW_CTRL0,
> > 			    QCA8K_GLOBAL_FW_CTRL0_CPU_PORT_EN);
> > 
> > doesn't that mean that using port 0 as a user port is double-broken,
> > since this would implicitly enable DSA headers on it?
> > 
> > Or is the idea of using port 6 as the CPU port to be able to use SGMII,
> > which is not available on port 0? Jonathan McDowell did some SGMII
> > configuration for the CPU port in commit f6dadd559886 ("net: dsa: qca8k:
> > Improve SGMII interface handling"). If the driver supports only port 0
> > as CPU port, and SGMII is only available on port 6, how did he do it?
> > 
> 
> I think the dotted thing in the diagram about sgmii is about the fact
> that you can use sgmii for both port0 or port6. (the switch configuration
> support only ONE sgmii) We have device that have such configuration
> (port0 set to sgmii) without the mac06 exchange bit set.

That's certainly the case for my device; the SGMII connection is treated
as port 0 (and connected to the CPU via that) and then port 6 uses its
own RGMII connection (both port0 + port6 have their own dedicated RGMII
pins on the chip, and then the SGMII is shared and selectable).

J.

-- 
If plugging it in doesn't help, turn it on.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux