From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Michael Walle <michael@walle.cc>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH net-next] net: phy: icplus: Call phy_restore_page() when phy_select_page() fails
Date: Wed, 17 Feb 2021 10:21:58 +0000 [thread overview]
Message-ID: <20210217102158.GE1463@shell.armlinux.org.uk> (raw)
In-Reply-To: <6a7032cea19b8798176012f128f4977a@walle.cc>
On Wed, Feb 17, 2021 at 11:12:11AM +0100, Michael Walle wrote:
> Am 2021-02-17 11:04, schrieb Russell King - ARM Linux admin:
> > On Wed, Feb 17, 2021 at 09:17:59AM +0300, Dan Carpenter wrote:
> > > Smatch warns that there is a locking issue in this function:
> > >
> > > drivers/net/phy/icplus.c:273 ip101a_g_config_intr_pin()
> > > warn: inconsistent returns '&phydev->mdio.bus->mdio_lock'.
> > > Locked on : 242
> > > Unlocked on: 273
> > >
> > > It turns out that the comments in phy_select_page() say we have to
> > > call
> > > phy_restore_page() even if the call to phy_select_page() fails.
> >
> > It seems it's a total waste of time documenting functions...
>
> You once said
>
> """
> Kernel development is fundamentally a difficult, frustrating and
> depressing activity.
> """
>
> But really this comment doesn't make it much better. Yes I've made
> a mistake although I _read_ the function documentation. So shame on
> me.
It wasn't aimed at you - it was more pointing out that in the normal
process of kernel development, reading documentation is fairly low,
yet we spend time creating it. So, does writing documentation actually
help, or does it just slow down the development cycle? Does it have a
net positive value? Personally, I don't think it does.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-02-17 10:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 6:17 [PATCH net-next] net: phy: icplus: Call phy_restore_page() when phy_select_page() fails Dan Carpenter
2021-02-17 7:52 ` Michael Walle
2021-02-17 10:04 ` Russell King - ARM Linux admin
2021-02-17 10:12 ` Michael Walle
2021-02-17 10:21 ` Russell King - ARM Linux admin [this message]
2021-02-17 14:28 ` Dan Carpenter
2021-02-17 15:06 ` Russell King - ARM Linux admin
2021-02-17 15:33 ` Russell King - ARM Linux admin
2021-02-17 17:06 ` Andrew Lunn
2021-02-17 21:24 ` Dan Carpenter
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=20210217102158.GE1463@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).