On Mon, Mar 13, 2017 at 07:06:25PM -0700, Doug Berger wrote: > On 03/13/2017 06:06 PM, Andrew Lunn wrote: > > On Mon, Mar 13, 2017 at 05:41:32PM -0700, Doug Berger wrote: > >> +static int bcm7xxx_28nm_ephy_01_afe_config_init(struct phy_device *phydev) > >> +{ > >> + int ret; > >> + > >> + /* set shadow mode 2 */ > >> + ret = phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, > >> + MII_BCM7XXX_SHD_MODE_2, 0); > >> + if (ret < 0) > >> + return ret; > >> + > >> + /* Set current trim values INT_trim = -1, Ext_trim =0 */ > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_BIAS_TRIM, 0x3BE0); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > >> + > >> + /* Cal reset */ > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, > >> + MII_BCM7XXX_SHD_3_TL4); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > > > > Hi Doug > > > > It would be nice to have a few blank lines here and there... > > > Thanks for taking the time to review this. > > In general I try to keep lines of related functionality together and use > the blank lines to help identify boundaries. In this particular case, I > believe it is clearer to keep the code that may return an error code > together with the code that tests for the error. Hi Doug I agree with that. Which is why i placed the comment between the goto and the next block of code. This is where i think there should be a blank line, to separate it from setting the trim values. > > return phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, 0, > > MII_BCM7XXX_SHD_MODE_2); > > > The trouble here is that currently the phy_set_clr_bits() function > returns the value written or a negative error and the function > bcm7xxx_28nm_ephy_01_afe_config_init() is supposed to return 0 on > success and non-zero on failure so this would not have the same > functionality. Ah, O.K. No problem. > >> + /* Advertise supported modes */ > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, > >> + MII_BCM7XXX_SHD_3_AN_EEE_ADV); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > > > > blank... > > > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT, > >> + MDIO_EEE_100TX); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > Here the two phy_write() calls are required to "/* Advertise supported > modes */" (one sets an address and the other specifies the data to write > to that address) so I kept them together to imply an association with > the preceding comment. O.K, i probably would if written a little helper function. And you seem to have this repeated a few times, so the helper would be used a few times. > >> + > >> + /* Restore Defaults */ > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, > >> + MII_BCM7XXX_SHD_3_PCS_CTRL_2); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT, > >> + MII_BCM7XXX_PCS_CTRL_2_DEF); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > Same here. > > >> + > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, > >> + MII_BCM7XXX_SHD_3_EEE_THRESH); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT, > >> + MII_BCM7XXX_EEE_THRESH_DEF); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > Here... > > >> + > >> + /* Enable EEE autonegotiation */ > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_ADDR_CTRL, > >> + MII_BCM7XXX_SHD_3_AN_STAT); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > >> + ret = phy_write(phydev, MII_BCM7XXX_SHD_2_CTRL_STAT, > >> + (MII_BCM7XXX_AN_NULL_MSG_EN | MII_BCM7XXX_AN_EEE_EN)); > >> + if (ret < 0) > >> + goto reset_shadow_mode; > and here. > > >> + > >> +reset_shadow_mode: > >> + /* reset shadow mode 2 */ > >> + ret = phy_set_clr_bits(phydev, MII_BCM7XXX_TEST, 0, > >> + MII_BCM7XXX_SHD_MODE_2); > >> + if (ret < 0) > >> + return ret; > >> + > >> + /* Restart autoneg */ > >> + phy_write(phydev, MII_BMCR, > >> + (BMCR_SPEED100 | BMCR_ANENABLE | BMCR_ANRESTART)); > >> + > >> + return 0; > > > > return phy_write(.....); ? > > > I would feel more comfortable with this if the return value of the > struct mii_bus write member function was more clearly defined. In our > case, we return 0 on success so I would consider this change, but I > would prefer a consensus that all mii_bus write functions return 0 on > success before doing so. You are right in that this is not clearly defined. But i just looked through all the mdio drivers in drivers/net/phy and they all do return 0 for their write operation. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html