Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 5 Jan 2023 11:49:18 +0100
From:   Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
To:     Leon Romanovsky <leon@kernel.org>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, Oleksij Rempel <o.rempel@pengutronix.de>
Subject: Re: [PATCH net-next 3/5] drivers/net/phy: add connection between
 ethtool and phylib for PLCA
Message-ID: <Y7arLoRBJ40eMizO@gvm01>
References: <cover.1672840325.git.piergiorgio.beruto@gmail.com>
 <5d9b49cb21c97bf187502d4f6000f1084a7e4df7.1672840326.git.piergiorgio.beruto@gmail.com>
 <Y7aSco7bDOHQhQv7@unreal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y7aSco7bDOHQhQv7@unreal>
Precedence: bulk

On Thu, Jan 05, 2023 at 11:03:46AM +0200, Leon Romanovsky wrote:
> On Wed, Jan 04, 2023 at 03:06:30PM +0100, Piergiorgio Beruto wrote:
> > This patch adds the required connection between netlink ethtool and
> > phylib to resolve PLCA get/set config and get status messages.
> > 
> > Signed-off-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
> > ---
> >  drivers/net/phy/phy.c        | 172 +++++++++++++++++++++++++++++++++++
> >  drivers/net/phy/phy_device.c |   3 +
> >  include/linux/phy.h          |   7 ++
> >  3 files changed, 182 insertions(+)
> 
> <...>
> 
> > +	curr_plca_cfg = kmalloc(sizeof(*curr_plca_cfg), GFP_KERNEL);
> > +	if (unlikely(!curr_plca_cfg)) {
> 
> Please don't put likely/unlikely on kamlloc and/or in in control path
> flow.
Fixed. Although, I am curious to know why exactly it is bad to
linkely/unlikely on kmalloc. Is this because if we're in a situation of
low memory we don't want to put more "stress" on the system failing
branch predictions?
> 
> Thanks