Re: [Patch net-next v2 0/9] net: dsa: microchip: add support for phylink mac config and link up
From: <Arun.Ramadoss@microchip.com>
Date: 2022-09-01 08:52:00
Also in:
lkml
On Wed, 2022-08-31 at 18:10 +0200, Oleksij Rempel wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Wed, Aug 31, 2022 at 06:18:59PM +0300, Vladimir Oltean wrote:quoted
On Wed, Aug 31, 2022 at 09:43:24AM +0200, Oleksij Rempel wrote:quoted
quoted
quoted
Should we point them to ksz8795_xmii_ctrl0 and ksz8795_xmii_ctrl1? I don't know. Could you find out what these should be set to?xmii_ctrl0/1 are missing and it make no sense to add it. KSZ8873 switch is controlling CPU port MII configuration over global, not port based register. I'll better define separate ops for this chip.Hm, not only KSZ8830/KSZ8863/KSZ8873 are affected. ksz8795 compatible series with defined .xmii_ctrl0/.xmii_ctrl1 are broken too. Because it is writing to the global config register over ksz_pwrite8 function. It means, we are writing to 0xa6 instead of 0x06. And to 0xf6 instead of 0x56.What do you mean by "global config register"? The Is_1Gbps bit is still part of a port register, it's just that this particular register is only defined for the 5th port (port #4, the only xMII port on KSZ7895 AFAIU). That doesn't necessarily make it a "global" register. Datasheet says: Register 22 (0x16): Reserved Register 38 (0x26): Reserved Register 54 (0x36): Reserved Register 70 (0x46): Reserved Register 86 (0x56): Port 5 Interface Control 6 I wonder if it's ok to modify the regs table like this, because we should then only touch P_XMII_CTRL_1 using port 4: static const u16 ksz8795_regs[] = { [REG_IND_CTRL_0] = 0x6E, [REG_IND_DATA_8] = 0x70, [REG_IND_DATA_CHECK] = 0x72, [REG_IND_DATA_HI] = 0x71, [REG_IND_DATA_LO] = 0x75, [REG_IND_MIB_CHECK] = 0x74, [REG_IND_BYTE] = 0xA0, [P_FORCE_CTRL] = 0x0C, [P_LINK_STATUS] = 0x0E, [P_LOCAL_CTRL] = 0x07, [P_NEG_RESTART_CTRL] = 0x0D, [P_REMOTE_STATUS] = 0x08, [P_SPEED_STATUS] = 0x09, [S_TAIL_TAG_CTRL] = 0x0C, [P_STP_CTRL] = 0x02, [S_START_CTRL] = 0x01, [S_BROADCAST_CTRL] = 0x06, [S_MULTICAST_CTRL] = 0x04, [P_XMII_CTRL_0] = 0x06, - [P_XMII_CTRL_1] = 0x56, + [P_XMII_CTRL_1] = 0x06, };Speed configuration on ksz8795 is done over two registers: Register 86 (0x56): Port 5 Interface Control 6: Is_1Gbps - BIT(6) and Register 6 (0x06): Global Control 4: Switch SW5-MII/RMII Speed -BIT(4) both are accessed on wrong offsets. I would prefer to do following steps: - remove everything from ksz_phylink_mac_link_up() except of dev->dev_ops->phylink_mac_link_up - move ksz_duplex_flowctrl(), ksz_port_set_xmii_speed()... to ksz9477.c and rename them. Assign ksz9477_phylink_mac_link_up() dev->dev_ops->phylink_mac_link_up - create separate function ksz8795_phylink_mac_link_up() - use documented, not generic register names.
In the original code, the ksz8795_cpu_interface_select (which does the xmii and speed configuration) is called only ksz87xx switch not for the ksz88x3. During refactoring, I intentionally did not add the P_XMII_CTRL0/1 for the ksz88xx in the chip_data structure. I added check that if switch belong to ksz88x3 then return in the phylink_mac_config function but I missed to add in the phylink_mac_link_up. Thats the mistake I have done. So, for the ksz88xx switch code breakage, it could be fixed by adding the check in the phylink_mac_link_up as well. For the code breakage in ksz8795/ksz8794, the original code has only provision for configuring xmii mode and choosing the 100/1000Mbps speed selection which could be selected using is_1Gbps bit of port5_interface_control6 register (0x56). But it didn't have provision to select speed between 10/100Mbps, flow control and duplex. As per vladimir suggestion, P_XMII_CTRL1 can be changed from 0x56 to 0x06. It fixes the problem for ksz_set_xmii, ksz_set_gbit since this is the port based register not the global register. The global register 0x06 responsibilities are bit 4 for 10/100mbps speed selection, bit 5 for flow control and bit 6 for duplex operation. Since these three are new features added during refactoring I overlooked it. To fix this, either I need to return from the ksz_set_100_10mbit & ksz_duplex_flowctrl function if the chip_id is ksz87xx or add dev-
dev_ops for this alone.
Kindly suggest on how to proceed.
-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/e/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917- 0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- 5555 |