> Sure, I can move this part to oa_tc6 lib. If I understand you correctly > you are talking about the Standard Capabilities Register (0x0002) > defined in the OPEN Alliance 10BASE-T1x MAC-PHY Serial Interface spec > right? If so, the 9th bit of this register tells about Indirect PHY > Register access Capability. Did you mean this bit? If so, this bit > describes the below, > > IPRAC - Indirect PHY Register Access Capability. Indicates if PHY > registers are indirectly accessible through the MDIO/MDC registers MDIOACCn. Yes. If the core relies on any functionality which is optional in the standard, it should check if the capability bit is set, and do a dev_erro() and return -ENODEV if a device does not actually have it. That makes it clear the core needs extending to support a device. If you are only using mandatory parts of the spec, then no test is needed. > > I would expect to see a call to phy_ethtool_ksettings_set() > > here. phylib should be able to do some of the validation. > Ah ok, doing the below will make the life easier. > .set_link_ksettings = phy_ethtool_set_link_ksettings, Please do some testing and check that phy_ethtool_set_link_ksettings doe actually reject all invalid setting. I cannot guarantee it does, and if it does not, it might actually be a PHY driver bug. > >> +static int lan865x_net_open(struct net_device *netdev) > >> +{ > >> + struct lan865x_priv *priv = netdev_priv(netdev); > >> + int ret; > >> + > >> + if (!is_valid_ether_addr(netdev->dev_addr)) { > >> + if (netif_msg_ifup(priv)) > >> + netdev_err(netdev, "Invalid MAC address %pm", netdev->dev_addr); > >> + return -EADDRNOTAVAIL; > > > > Using a random MAC address is the normal workaround for not having a > > valid MAC address via OTP flash etc. > Ah ok, you mean to use eth_hw_addr_random(netdev) instead of returning > error. Yes. And this is generally done earlier than open, as part of probe. You want to avoid surprising userspace when the MAC address suddenly changes at open time. Andrew