From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [PATCH net-next] net: phy: fix two issues with linkmode bitmaps Date: Sun, 25 Nov 2018 21:47:53 +0100 Message-ID: <20181125204753.GG18663@lunn.ch> References: <7851597d-e582-379f-f158-8d103a895720@gmail.com> <20181125164513.GD18663@lunn.ch> <3917cdd2-ae04-7392-4b08-cf2d15082dcd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Fainelli , David Miller , "netdev@vger.kernel.org" To: Heiner Kallweit Return-path: Received: from vps0.lunn.ch ([185.16.172.187]:48512 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbeKZHjx (ORCPT ); Mon, 26 Nov 2018 02:39:53 -0500 Content-Disposition: inline In-Reply-To: <3917cdd2-ae04-7392-4b08-cf2d15082dcd@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: > Eventually we'd have three types of mii_xxx_to_linkmode_yyy functions: > > 1. Function first zeroes the destination linkmode bitmap > 2. Function sets bits in the linkmode bitmap but doesn't clear bits > if condition isn't met > 3. Function clears / sets bits it's responsible for > > example case 1: mmd_eee_adv_to_linkmode > example case 2: mii_stat1000_to_linkmode_lpa_t > example case 3: what you just proposed as fix for > mii_adv_to_linkmode_adv_t > > Because function naming is the same I'm afraid they easily can be used > incorrectly (the bugs we just discuss are good examples). Maybe it > could be an option to reflect the semantics in the name like this > (better suited proposals welcome): > > case 1: mii_xxx_to_linkmode_yyy > case 2: mii_xxx_or_linkmode_yyy > case 3: mii_xxx_mod_linkmode_yyy Hi Heiner That is a good idea. We should probably do this first, it will help find the bugs. Andrew