| Message ID | 20230808021708.196160-2-jiawenwu@trustnetic.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | support more link mode for TXGBE | expand |
On Tue, Aug 08, 2023 at 10:17:02AM +0800, Jiawen Wu wrote: > Since Wangxun 10Gb NICs require some special configuration on the IP of > Synopsys Designware XPCS, introduce dev_flag for different vendors. The > vendor identification of wangxun devices is added by comparing the name > of mii bus. > > And interrupt mode is used in Wangxun devices, so make it to be the first > specific configuration. > > Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Does the XPCS in Wangxun devices have the device identifiers (registers 2 and 3) and the package identifiers (registers 14 and 15) implemented, and would they be set to an implementation specific value that would allow their integration into Wangxun devices to be detected? If the answer to that is yes, it would be preferable to use that rather than adding a bitarray of flags to indicate various "quirks". Thanks.
On Tue, Aug 08, 2023 at 05:46:03PM +0800, Jiawen Wu wrote: > On Tuesday, August 8, 2023 5:21 PM, Russell King (Oracle) wrote: > > On Tue, Aug 08, 2023 at 10:17:02AM +0800, Jiawen Wu wrote: > > > Since Wangxun 10Gb NICs require some special configuration on the IP of > > > Synopsys Designware XPCS, introduce dev_flag for different vendors. The > > > vendor identification of wangxun devices is added by comparing the name > > > of mii bus. > > > > > > And interrupt mode is used in Wangxun devices, so make it to be the first > > > specific configuration. > > > > > > Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> > > > > Does the XPCS in Wangxun devices have the device identifiers (registers > > 2 and 3) and the package identifiers (registers 14 and 15) implemented, > > and would they be set to an implementation specific value that would > > allow their integration into Wangxun devices to be detected? > > > > If the answer to that is yes, it would be preferable to use that > > rather than adding a bitarray of flags to indicate various "quirks". > > It has not been implemented yet. We could implement it in flash if it's wanted. > But it would require upgrading to the new firmware. Andrew, do you any opinions? Do you think it would be a good idea to use the device/package identifiers, rather than a bitfield of quirks? > BTW, how do we make sure this value doesn't conflict with other device vendors? PHY identifiers are based on the OUI (which is the same as what gets used in the first three bytes of MAC addresses). For example, Marvell is 00:50:43, which is in binary: 0000 0000 0101 0000 0100 0011 Their PHY IDs are generally 0x01410c00-0x01410fff, which is in binary: 0000 0001 0100 0001 0000 11xx and if we shift the OUI by two bits to the right, we end up with the number in the PHY. 802.3 22.2.4.3.1 says: The PHY Identifier shall be composed of the third through 24th bits of the Organizationally Unique Identifier (OUI) assigned to the PHY manufacturer by the IEEE,1 plus a six-bit manufacturer’s model number, plus a four-bit manufacturer’s revision number. 45.2.1.3 PMA/PMD device identifier (Registers 1.2 and 1.3) ... The identifier shall be composed of the 3rd through 24th bits of the Organizationally Unique Identifier (OUI) assigned to the device manufacturer by the IEEE, plus a six-bit model number, plus a four- bit revision number. A PMA/PMD may return a value of zero in each of the 32 bits of the PMA/PMD device identifier to indicate that a unique identifier as described above is not provided. The format of the PMA/PMD device identifier is specified in 22.2.4.3.1. 45.2.1.13 PMA/PMD package identifier (Registers 1.14 and 1.15) ... The identifier shall be composed of the 3rd through 24th bits of the Organizationally Unique Identifier (OUI) assigned to the package manufacturer by the IEEE, plus a six-bit model number, plus a four-bit revision number. A PMA/PMD may return a value of zero in each of the 32 bits of the package identifier. A non-zero package identifier may be returned by one or more MMDs in the same package. The package identifier may be the same as the device identifier. The format of the package identifier is specified in 22.2.4.3.1.
> > > If the answer to that is yes, it would be preferable to use that > > > rather than adding a bitarray of flags to indicate various "quirks". > > > > It has not been implemented yet. We could implement it in flash if it's wanted. > > But it would require upgrading to the new firmware. > > Andrew, do you any opinions? Do you think it would be a good idea to > use the device/package identifiers, rather than a bitfield of quirks? Using identifiers would be cleaner. Does trustnetic or net-swift have an OUI? Andrew
On Wednesday, August 9, 2023 4:42 AM, Andrew Lunn wrote: > > > > If the answer to that is yes, it would be preferable to use that > > > > rather than adding a bitarray of flags to indicate various "quirks". > > > > > > It has not been implemented yet. We could implement it in flash if it's wanted. > > > But it would require upgrading to the new firmware. > > > > Andrew, do you any opinions? Do you think it would be a good idea to > > use the device/package identifiers, rather than a bitfield of quirks? > > Using identifiers would be cleaner. > > Does trustnetic or net-swift have an OUI? Yes, net-swift's OUI is 30:09:F9. But if we want to read OUI from PCS to identify the vendor, we need the next version of firmware to do this. How can this be compatible with the old firmware version?
> Yes, net-swift's OUI is 30:09:F9. > > But if we want to read OUI from PCS to identify the vendor, we need the > next version of firmware to do this. How can this be compatible with the > old firmware version? In general, the driver should offer only the features the firmware supports. So if you find a PCS with the old OUI, don't offer the link modes which require the PCS configured in special ways. You can also issue a warning that the firmware should be upgraded. Andrew
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c index 44b037646865..88c5e36735b6 100644 --- a/drivers/net/pcs/pcs-xpcs.c +++ b/drivers/net/pcs/pcs-xpcs.c @@ -238,6 +238,12 @@ static int xpcs_write_vpcs(struct dw_xpcs *xpcs, int reg, u16 val) return xpcs_write_vendor(xpcs, MDIO_MMD_PCS, reg, val); } +static void xpcs_dev_flag(struct dw_xpcs *xpcs) +{ + if (!strcmp(xpcs->mdiodev->bus->name, "txgbe_pcs_mdio_bus")) + xpcs->dev_flag = DW_DEV_TXGBE; +} + static int xpcs_poll_reset(struct dw_xpcs *xpcs, int dev) { /* Poll until the reset bit clears (50ms per retry == 0.6 sec) */ @@ -1284,12 +1290,14 @@ static struct dw_xpcs *xpcs_create(struct mdio_device *mdiodev, goto out; } + xpcs_dev_flag(xpcs); xpcs->pcs.ops = &xpcs_phylink_ops; xpcs->pcs.neg_mode = true; if (compat->an_mode == DW_10GBASER) return xpcs; - xpcs->pcs.poll = true; + if (xpcs->dev_flag != DW_DEV_TXGBE) + xpcs->pcs.poll = true; ret = xpcs_soft_reset(xpcs, compat); if (ret) diff --git a/include/linux/pcs/pcs-xpcs.h b/include/linux/pcs/pcs-xpcs.h index ff99cf7a5d0d..29ca4c12d044 100644 --- a/include/linux/pcs/pcs-xpcs.h +++ b/include/linux/pcs/pcs-xpcs.h @@ -20,12 +20,16 @@ #define DW_AN_C37_1000BASEX 4 #define DW_10GBASER 5 +/* dev_flag */ +#define DW_DEV_TXGBE BIT(0) + struct xpcs_id; struct dw_xpcs { struct mdio_device *mdiodev; const struct xpcs_id *id; struct phylink_pcs pcs; + int dev_flag; }; int xpcs_get_an_mode(struct dw_xpcs *xpcs, phy_interface_t interface);
Since Wangxun 10Gb NICs require some special configuration on the IP of Synopsys Designware XPCS, introduce dev_flag for different vendors. The vendor identification of wangxun devices is added by comparing the name of mii bus. And interrupt mode is used in Wangxun devices, so make it to be the first specific configuration. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> --- drivers/net/pcs/pcs-xpcs.c | 10 +++++++++- include/linux/pcs/pcs-xpcs.h | 4 ++++ 2 files changed, 13 insertions(+), 1 deletion(-)