From: Andrew Lunn <andrew@lunn.ch> To: Doug Berger <opendmb@gmail.com> Cc: f.fainelli@gmail.com, robh+dt@kernel.org, mark.rutland@arm.com, davem@davemloft.net, rafal@milecki.pl, xow@google.com, joel@jms.id.au, jon.mason@broadcom.com, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, pgynther@google.com, jaedon.shin@gmail.com Subject: Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY Date: Tue, 14 Mar 2017 03:43:20 +0100 [thread overview] Message-ID: <20170314024320.GQ15842@lunn.ch> (raw) In-Reply-To: <3e5f7ac9-7e97-60f1-3986-4045522a65f5@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> To: Doug Berger <opendmb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org, xow-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org, jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, pgynther-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, jaedon.shin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Subject: Re: [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY Date: Tue, 14 Mar 2017 03:43:20 +0100 [thread overview] Message-ID: <20170314024320.GQ15842@lunn.ch> (raw) In-Reply-To: <3e5f7ac9-7e97-60f1-3986-4045522a65f5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-14 2:43 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-14 0:41 [PATCH net-next 00/12] net: bcmgenet: add support for GENETv5 Doug Berger 2017-03-14 0:41 ` Doug Berger 2017-03-14 0:41 ` [PATCH net-next 01/12] net: phy: bcm-phylib: replace obsolete EEE macro references Doug Berger 2017-03-14 0:49 ` Florian Fainelli 2017-03-14 0:49 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 02/12] net: phy: bcm7xxx: add support for 28nm EPHY Doug Berger 2017-03-14 0:50 ` Florian Fainelli 2017-03-14 0:50 ` Florian Fainelli 2017-03-14 1:06 ` Andrew Lunn 2017-03-14 1:06 ` Andrew Lunn 2017-03-14 2:06 ` Doug Berger 2017-03-14 2:43 ` Andrew Lunn [this message] 2017-03-14 2:43 ` Andrew Lunn 2017-03-14 17:23 ` Doug Berger 2017-03-14 17:23 ` Doug Berger 2017-03-14 0:41 ` [PATCH net-next 03/12] net: bcmgenet: simplify circular pointer arithmetic Doug Berger 2017-03-14 0:54 ` Florian Fainelli 2017-03-14 0:54 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 04/12] net: bcmgenet: remove meaningless lines Doug Berger 2017-03-14 0:55 ` Florian Fainelli 2017-03-14 0:55 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 05/12] net: bcmgenet: manage dma interrupts in napi code Doug Berger 2017-03-14 0:55 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 06/12] net: bcmgenet: remove handling of wol interrupts from isr0 Doug Berger 2017-03-14 0:41 ` Doug Berger 2017-03-14 0:56 ` Florian Fainelli 2017-03-14 0:56 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts Doug Berger 2017-03-14 0:56 ` Florian Fainelli 2017-03-14 0:56 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 08/12] net: bcmgenet: correct return value of __bcmgenet_tx_reclaim Doug Berger 2017-03-14 0:57 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 09/12] net: bcmgenet: return EOPNOTSUPP for unknown ioctl commands Doug Berger 2017-03-14 0:57 ` Florian Fainelli 2017-03-14 11:04 ` David Laight 2017-03-14 17:31 ` Doug Berger 2017-03-14 0:41 ` [PATCH net-next 10/12] dt-bindings: net: document bcmgenet WoL interrupt Doug Berger 2017-03-14 0:58 ` Florian Fainelli 2017-03-14 0:58 ` Florian Fainelli 2017-03-20 22:09 ` Rob Herring 2017-03-20 22:09 ` Rob Herring 2017-03-14 0:41 ` [PATCH net-next 11/12] dt-bindings: net: update bcmgenet binding for GENETv5 Doug Berger 2017-03-14 0:58 ` Florian Fainelli 2017-03-14 0:41 ` [PATCH net-next 12/12] net: bcmgenet: add support for the GENETv5 hardware Doug Berger 2017-03-14 0:59 ` Florian Fainelli 2017-03-14 0:59 ` Florian Fainelli 2017-03-14 4:53 ` [PATCH net-next 00/12] net: bcmgenet: add support for GENETv5 David Miller 2017-03-14 4:53 ` David Miller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170314024320.GQ15842@lunn.ch \ --to=andrew@lunn.ch \ --cc=davem@davemloft.net \ --cc=devicetree@vger.kernel.org \ --cc=f.fainelli@gmail.com \ --cc=jaedon.shin@gmail.com \ --cc=joel@jms.id.au \ --cc=jon.mason@broadcom.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=netdev@vger.kernel.org \ --cc=opendmb@gmail.com \ --cc=pgynther@google.com \ --cc=rafal@milecki.pl \ --cc=robh+dt@kernel.org \ --cc=xow@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.