Re: [RFC PATCH v3 net-next 2/6] net: phylink: introduce a generic method for querying PHY in-band autoneg capability

On Thu, Sep 23, 2021 at 12:03:22AM +0100, Russell King (Oracle) wrote:

On Wed, Sep 22, 2021 at 09:48:28PM +0000, Vladimir Oltean wrote:

quoted

On Thu, Sep 23, 2021 at 12:31:16AM +0300, Vladimir Oltean wrote:

quoted

On Wed, Sep 22, 2021 at 10:22:19PM +0100, Russell King (Oracle) wrote:

quoted

On Wed, Sep 22, 2021 at 09:14:42PM +0300, Vladimir Oltean wrote:

quoted

+static unsigned int phylink_fixup_inband_aneg(struct phylink *pl,
+					      struct phy_device *phy,
+					      unsigned int mode)
+{
+	int ret;
+
+	ret = phy_validate_inband_aneg(phy, pl->link_interface);
+	if (ret == PHY_INBAND_ANEG_UNKNOWN) {
+		phylink_dbg(pl,
+			    "PHY driver does not report in-band autoneg capability, assuming %s\n",
+			    phylink_autoneg_inband(mode) ? "true" : "false");
+
+		return mode;
+	}
+
+	if (phylink_autoneg_inband(mode) && !(ret & PHY_INBAND_ANEG_ON)) {
+		phylink_err(pl,
+			    "Requested in-band autoneg but driver does not support this, disabling it.\n");

If we add support to the BCM84881 driver to work with
phy_validate_inband_aneg(), then this will always return
PHY_INBAND_ANEG_OFF and never PHY_INBAND_ANEG_ON. Consequently,
this will always produce this "error". It is not an error in the
SFP case, but it is if firmware is misconfigured.

So, this needs better handling - we should not be issuing an error-
level kernel message for something that is "normal".

Is this better?

		phylink_printk(phy_on_sfp(phy) ? KERN_DEBUG : KERN_ERR, pl,
			       "Requested in-band autoneg but driver does not support this, disabling it.\n");

Ah, not sure whether that was a trick question or not, but
phylink_fixup_inband_aneg function does not get called for the SFP code
path, I even noted this in the commit message but forgot:

No it wasn't a trick question. I thought you were calling
phylink_fixup_inband_aneg() from phylink_sfp_config(), but I see now
that you don't. That's what happens when you try and rush to review.

How did I "rush to review" exactly? I waited for 24 days since the v2
for even a single review comment, with even a ping in between, before
resending the series largely unaltered, just with an extra patch appended.

Not complaining that you haven't reviewed this in 24 days, we all have
other things to do, but, "rush"? I have genuinely forgotten the
implementation details of the patches already, and I don't have any medical
issues with the memory that I know of (or I may have forgotten about them too).

So let's say I want to strike a balance between not rushing reviewers
and being able to usefully respond to questions. What is a good waiting time?
It is generally accepted on netdev that if there is no reaction within 3
days, then "out of sight" becomes "out of mind".

Also, "that's what happens" => what? Some confusion, which gets clarified
over two email exchanges in a few tens of minutes? Is that so bad?